Potential Cards

[ShawnieBoy]

It has been mentioned before that it can be tricky to find new cards to add to Magarena, taking into account AI and other restrictions.

I usually have an ongoing list of cards to consider (which I normally then misplace) while looking through Card Explorer. I thought it would be handy for everyone (and a safe place to put my list) if I posted it here for others to have a look over.

I'll try and keep this up to date with submissions through Firemind and on the main repo, to try not to have multiple people doing the same cards (although this can be helpful for tricky ones.)

As Mirrodin Besieged and Nemesis have now joined the 80% complete club, these are what I've looked at so far - some more tricky than others, but should be worth looking at:

Eye of Yawgmoth
Cryptoplasm
Distant Memories
Galvanoth
Gore Vassal
Gruesome Encore
Knowledge Pool
Mitotic Manipulation
Phyrexian Rebirth
Piston Sledge
Praetor's Counsel
Rupture (The sacrifice here isn't a cost, it's an effect of the spell resolving)
Tezzeret, Agent of Bolas
Virulent Wound
Kill Switch
Wild Mammoth (Essentially doesn't trigger if there is a draw)

[mike]

This reminds me that I've been meaning to implement something like this as part of firemind for ages.

Some way to track what cards are implemented in HEAD that are not part of the last release, see what cards could be added and which ones are currently impossible (by flagging them with the reason they are not doable). Maybe even allow users to say what cards they are currently working on. Basically anything to make the scripters life easier and make the request cards feature actually useful.

I guess my question is: Would anyone even use it? And if so what features would you like to have?

[ShawnieBoy]

Cool idea

The upcoming cards list in my sig is updated by Melvin for cards that have been done but not released (and so submissions would be duplicates).

Being able to flag impossible cards would be useful too. I've not kept an eye on submissions via Firemind, but wouldn't be a bad thing to have.

[melvin]

Wow, I just thinking about similar things as well. How to make it easier to find scriptable cards by separating the unsupported cards from the scriptable ones.

My idea is to use the cards already in the release folder, now all under scripts_missing. I'm thinking to create two sub directories, perhaps a "scriptable" and "unsupported". The generic scripts_missing contains uncategorized cards, then over time as we analyze each one, we move them to the appropriate subdirectories.

[mike]

My idea is to use the cards already in the release folder, now all under scripts_missing. I'm thinking to create two sub directories, perhaps a "scriptable" and "unsupported".

Some of the cards that are currently unsupported could become supported in the future as the game engine improves right? Having all of them in one folder might become cumbersome to keep up to date especially if not everyone maintaining it is sure about why a card was marked as unsupported originally. Which is why I thought about a tagging system where you could have an unsupported tag name like "Suspend" with a description of why suspend is not currently supported. If it later becomes supported it would be easy to find the cards that are now scriptable. Admittedly this isn't as much of a problem if the reason is an unsupported keyword for which people can search but if the reason is something like the "multiple mana problem" it might be useful to have the cards tagged.

[mike]

So I've been playing around a little with the idea and came up with a prototype: https://www.firemind.ch/workspace

It lets you find cards to script, create card script submissions directly and see the status of your submissions. Users who have been given access may also create "Not Implementable Reasons" and tag cards with them. I did that for Banding, Suspend, Phasing and the" multiple choices on modal spells"-problem.

What's missing is the integration with the magarena git repository. Here's my proposal for doing that:

* I create a new branch on https://github.com/firemind/magarena-csm-auto which I regularly update from magarena/magarena master
* Cards that are present in that branches release/Magarena/scripts directory but not in the last magarena release will be flagged as "upcoming" and excluded from the "Find card to work on search" by default
* If a card gets tagged with a reason for not being implementable it gets moved to scripts/missing/unsupported on my branch if it's not already there
* The reason(s) get added as the last line of the script file. Something like

Code: Select all

not_implementable_because=[Banding],[Phasing]

* The changes in my branch are commited as the user who performed them and pushed. Just like the card script submissions work currently
* If the unsupported tagging happens manually on the master branch my sync will update the firemind database accordingly
* If tags are removed on either side I'll update the other side

What do you think about having this feature and doing it this way?

As a side note: Would it be useful if instead of commiting all the card submissions to magarena-csm-auto:master I created a new branch and a pull request automatically for each of them? https://developer.github.com/v3/pulls/# ... ll-request

[melvin]

So I've been playing around a little with the idea and came up with a prototype: https://www.firemind.ch/workspace

Thanks, mike, I just gave it a spin. Looks pretty handy, though I'll probably will operate on the repository directly rather than through a web interface as it is faster for me.

The idea of using a property in the card script is a good one. It is more flexible than using directories and keeps track of the reason as well. Though one issue may be problems with card-builder, as we sometimes will regenerate the missing scripts when card-builder is updated. @ShawnieBoy what do you think?

Assuming a property in the card script is the way to go, we also want to track groovy scriptable cards vs cards that have not been analyzed. I'd like to propose the following format

Code: Select all

status=needs groovy
status=not supported: banding, phasing


[melvin]

As a side note: Would it be useful if instead of commiting all the card submissions to magarena-csm-auto:master I created a new branch and a pull request automatically for each of them?

For card submissions, committing to the repo is easier to work with than pull requests. I'd prefer to stick to the current method.

[ShawnieBoy]

With regards to the scriptsbuilder, there needs to be a manual oversee of the card values and images, so wouldn't have that much extra impact. It could even be possible to take the results of the ParsedCards output and assign the "uknown abilty" errors etc to the statuses.

[mike]

I'll probably will operate on the repository directly rather than through a web interface as it is faster for me.

That's cool. I wasn't expecting core devs to switch to this.

I see the main audience in people who occasionally want to work on a card or are just starting to get into card scripting. This is supposed to lower the barrier of entry by communicating clearly to people what cards can and cannot be worked on which should help prevent frustration. In addition I'd like to implement some advanced search to help find similar cards that already have a card script to serve as a base for new scripts.

Code: Select all

status=needs groovy
status=not supported: banding, phasing

Alright, is that the syntax that works best for everyone? If so I'll add a check box for the "needs groovy"-status and get to work on the sync.

[melvin]

In addition I'd like to implement some advanced search to help find similar cards that already have a card script to serve as a base for new scripts.

Finding a similar groovy script to based a new script on would be an extremely helpful feature. I'm currently using grep for this. A more sophisticated groovy search feature would come in handy.

Alright, is that the syntax that works best for everyone? If so I'll add a check box for the "needs groovy"-status and get to work on the sync.

Perhaps we can trial it in the repo for the next release to get a better feel of how it works in practice. Note that the directory structure remains unchanged, there will be no new subdirectories.

One short coming I realized is that "needs groovy" doesn't give enough details as to which ability needs to be written in groovy. There are some cards where two out of the three abilities works as it in card script and one of them needs to be implemented in groovy. Perhaps we can create a stub groovy file that has the oracle text in comments.

[mike]

Perhaps we can trial it in the repo for the next release to get a better feel of how it works in practice.

Ok, so I set up a new branch at https://github.com/firemind/magarena-cs ... lementable

The system will commit added or removed labels to this branch with the user that makes the changes. I tested that with the banding, phasing and suspend labels I created.

I'm updating my clone from magarena/magarena hourly and update the firemind database with all labels that are added directly via the repository.

Let me know if this works for you.

[melvin]

Thanks, mike. I've manage to squashed and rebased the commits that adds status property back to the main repo and added a few more. Feels good to get a better handle on the missing cards.

[mike]

That's great! Just let me know if you have any ideas to improve the system further.

Improving the search is still on my radar. It's just a bit trickier than I thought.

[ShawnieBoy]

Just added a filter for cards with no status, or not 'not supported'

Is there a list of not-supported tags available?