GUI Card Editor

[drdev]

So I've been thinking, and I think the project I really want to tackle is to create a GUI screen for creating and managing card scripts. At its simplest it would provide the same Card Catalog pane as the Deck Editor, with the ability to double-click a card to open it's script in a text box for viewing/editing, along with buttons to Save changes and Restore from file (reverting any changes made).

From there, I think it would be good to add the list of remaining cards to the source such that we could display that list in the GUI, with the ability to double-click to create the script for that card. That way, when somebody creates a script for a card, it automatically updates the remaining cards list for everyone. Then, each time a new set is released (or card previews are up), we can update the list in the source so people know they can start scripting the cards. We could even provide a link for each card so the user can easily jump to a web page where they can view the card.

From there, what I really want to do is provide support for creating custom cards and sets and lower the barrier to entry. What I mean by that is, in addition to having a script view where you can view and edit the script text, I hope to add a card forge view (get it?) where you can utilize discrete input controls to define the card's name, type, subtype(s), mana cost, color, abilities (static, activated, and triggered), and flavor text. We'd then use these fields to generate the script for you, and you'd be able to come back later and tweak these fields and modify the script. Such a feature would also make creating scripts for many real magic cards much faster, and offer programmatic validation of the scripts to reduce bugs.

In addition, for custom cards, we could offer the ability to create an image for the card by selecting a frame (we'd want to probably design our own frame options for this to distinguish custom cards, unless we provide an option to download frames from a site like Magic Set Editor), and importing any image they want. It'd be Magic Set Editor where you can play with the cards against AI. Obviously we'd only be able to support scriptable cards (unlike Magic Set Editor), but our scripting engine is so robust the limitations wouldn't be too bad. Even if they wanted to create a card our engine couldn't support without writing new Java code, we could have some built in way of sending an enhancement request to the developer group for someone to add the necessary code.

The user could use the Card Editor to create an entire set of custom cards (with the ability to name the set, create a set symbol, and provide a description/back story), have the set live on their machine only by default, and have it be available in Deck Editor (and maybe even used for random deck generation based on a setting). But where it could get really cool is to allow users to share their custom sets with everyone by exporting to a zip file, uploading that file to some site we manage, and then allowing other users to download sets from that site and import them into Forge.

What do you think?

[friarsol]

I guess I have mixed feelings about this. There are definitely parts that I think will be pretty useful (on the fly reloading of scripts in particular). Please read this with a tone of reservation, not with a negative one. Hopefully it doesn't come out that way.

While we don't specifically have a "remaining cards" list per se, we do have the lists of all the cards inside /res/editions/* if you just flatten the set lists of distinct cards, subtract out the cards that exist, then you have the remaining cards. In addition to that, we do have Python scripts that parse a separate mtg data file, compare it to the card scripts for the stats that I post up, and use for other things. Considering we currently have only 360 cards left, I'm not sure if it would be worth the effort to track this differently than how it's being tracked now. The spreadsheet I compiled isn't just a list of cards, it's organized by what the card does. E.g. We have 25 cards that aren't scripted because we don't have a way for an opponent to choose targets for a Spell/Ability. We wouldn't be able to know this by just glancing at a list of 360 cards.

Additionally, the system we use now for scripting new sets works pretty smoothly. As spoilers come out, people script them and add the new scripts to a different branch. This happens way before a full list of the set is out. No need for overhead of updating the source with lists; people call dibs on cards, and they script them continuously during spoiler season. A few days before the prerelease when the full list is out, the editions file is updated, the scripts are merged in, and voila tons of new cards that Forge supports.

While the general idea of supporting custom sets is good, is the entry level really that daunting? There's definitely some boiler plating that each script needs, I suppose some type of syntactic compiler and requirements tool could come in handy. But I wouldn't say the barrier is all that large, there's a few people who are working on their own custom sets right now. There are plenty of people who work mostly on scripts, came in and just started working, learning the system from the Wiki and comparing the card they want with existing ones. And asking questions on the boards.

Proliferation of Custom Set sharing could definitely be useful. I'm sure it'd be important to have both easy access for downloading, but also potentially voting so you know which sets are actually worth trying out.

[Max mtg]

I never expected to use a visual editor for that task... don't know if it will accelerate card scripting for developers (in most cases I just copy-pasted a similiar card to make a new one and changed that copied script)

What would come handy for sure is the ability to reload a single card's script without restarting the application (and as an extra scan folders for new, not-yet-loaded scripts)
It is a CardRules object that holds all data. Ingame cards are build based on these. So cards are to be updated only between games.

There are edition desciption files in /res/editions/*. The card lists these contain are read into CardEdition instances, regardless of whether the card has been scripted or not. You may derive remaining cards from these lists.

In a scenario when user is to implement a new set, he creates edition desciption file first, and then might use your missing cards list, filtered by custom editions for instance. The current new set scripting pipeline won't be affected.

[drdev]

I was thinking that I would add support for creating a new card using an existing card as a template, so it sounds like that would fit into your current workflow.

Since it sounds like the process for remaining and new cards is working well, I won't mess with it. I'll instead focus on my idea for custom set building and generating scripts from discrete fields.