Collectible Card Game Headquarters

I've mentioned my intent to work on this in the past, but in light of challenges I encountered trying to update the script files recently, I decided to get it going now. I'm happy to reveal the first iteration of the Workshop screen.


As of right now, all you can do on this screen is select existing cards to view and edit their script, with a button to save any changes back to the .txt file. Given the Catalog here offers the same search capabilities as the Deck Editor one, it should make tracking down cards to update much easier than searching the cardsfolder directory.

The next step I'm planning is to make is to update the CardRules immediately when saving changes, meaning you won't have to restart Forge to test out any script changes. This might prove tricky, and I may have to disable saving while a game is active to make it work, but it should make testing new script changes much faster, particular if it takes a few tries to get it right.

After that, I still hope to flesh out the Card Designer pane with controls for generating the script, and eventually add support for creating custom cards and sets to the Workshop. Until then, this screen won't be useful to non-developers, and I'm open to hiding it if not in Developer mode or not running from source. Just let me know.

Let me know if you have any questions or feedback. Happy scripting.
-Dan

A quick update. I've added a File menu with a Save item (Ctrl+S shortcut), undo/redo support (with the new classes FTextEditor and FUndoManager that can be reused elsewhere), a prompt to save when switching away from a card with unsaved changes (either to a different card or different screen), and support for updating rules and display of the card when saving.

I'm still looking for feedback, particularly in terms of any risks with modifying CardRules, PaperCard, and Card instances after Forge initially loads, and in terms of the conditions under which the Workshop should be available and/or editing allowed. I'd also like for people making card script changes right now to try using the screen and let me know what I could improve.

Thanks.
-Dan

(Please note, I haven't had time to mess around with it yet, so these are mostly general observations from the screenshot and your explanation)

I'm not sure if one day is enough time to start worrying that noone has responded about your changes. Personally, the only time I would see myself using this immediately is for instantaneous card changes. (Would there be a way to do this with externally saved files?) It appears to be much easier for me to work in Sublime Text than within Forge itself.

The most important thing that I use in my text editor is file searching, which searches the actual text of the scripts, and not just the text of the card. It doesn't care all that much that things are in different folders, it just searches through all of the files. But other things like being able to open up multiple tabs for scrap pasting. Friendly keyboard shortcuts, fast response times.

Things that the "Workshop" could do that a simple editor wouldn't be able to do: Card Templating, we have a Python script that.. Moomarc(I think?) wrote that you generates a base Script. Syncing this with real data would be handy, but since there are so few unscripted cards remaining there's really diminishing returns here, considering future cards generally never have an official source when they are scripted. Automatically add "References" parameter, automatically add Oracle text. Perhaps even some rudimentary script verification (for Workshop 2.0).

I'd imagine Max is the best person to respond to risks of modifying Card and friends objects on the fly, since he extracted most of that from where it was living. I'd think that the Workshop should only be available from a hidden menu somewhere, and it shouldn't be accessible once a game is in session. Although you'd have to be careful about a Workshop->Match->Workshop scenario when all you want to do is test one card.

frialsol, thank you for the feedback. Also, I'm sorry if I came off as rushing feedback, I only wanted to make sure people had seen this thread given that almost all the activity in the Developer's Corner forum has been in the first couple stickied threads, making scrolling down to find others typically unnecessary.

Also, as far as hiding the Workshop in the menus, I was more thinking along the lines of hiding it unless running from source and/or in Developer Mode. Eventually when support for adding custom cards/sets is added (which I'm planning for later), the Workshop screen will useful even to non-Developers, in which case we'd probably just lock down editing of real Magic cards (they'd be able to duplicate existing cards under a new name though).

As a side note, the Forge menu is meant for actions specific to the current screen, not so much for launching other screens. Screens tabs should either be open all the time (Home and Deck Editor), or else opened from a screen via button, with the ability to close that screen later. I see Workshop being more like Deck Editor, hence having its tab always open or always hidden (based on preferences and/or version type).

With all that said, in response to your other feedback, I'll look into the following enhancements:

• Add a tool for easily searching through all the script text itself (both for current card and all cards), as well offer Replace and Replace All options
• Add syntax highlighting for the scripting language's keywords, as well as highlighting search matches in the text
• Add a menu shortcut to open the current card's script in a configurable external editor, with support for updating the CardRules when you return to Forge after making changes in that editor

How does that list sound? Anything else I could add?

friarsol, I see the value in the Forge Workshop as an answer to the many requests for easy addition of custom cards and sets. While the remaining cards aren't scriptable (yet) there will always be new basic cards that can be handled easy by nearly anyone.

I envision this becoming like an IDE for Forge cards.. Being able to manipulate all the card data graphically or textually. Click the picture to change it and set URL; Add/Remove keywords via list boxes and combo box; Ability building wizards; change set membership; add/remove/modify set data; etc.

I don't think it should be limited to dev mode or running from source, it would be better if it were an external tool. May not be easy, but with the work you guys have done to separate the other parts, it's certainly possible. (need to break out the common UI and Card db objects)

Good work drdev.

While the idea is really great, the last implementation broke the applciation architecture.
Some classes that are supposed to be project's foundation were intended to be very simple and have minimum references, like classes implementing color, type, mana cost and the paper card itself.

Thus, PaperCard must not have any reference to ingame card classes. And this code is completelly unviable.

Code: Select all

   
    public void updateRules(String script) {
       CardRulesReader.updateCardRules(this.rules, script);
       this.name = this.rules.getName();
       Card.updateCard(this);
    }


Also, papercard's name must stay a final field. If you need a card with different name, create a new instance. If you want to change card's name, that task should be delegated to CardDb (only that class would be able to update its indices properly and add new CardPrinted). I'll help you with the core classes, just tell me what you need.

In the same manner, CardRules must not contain any paths, because it's a class to hold rules, not paths to files. Make a separate map if you need to match rules agains files or vice versa.

Now, when core classes were moved to core project, I hope it will be much harder to violate these principles.

There's even more - I had to rollback some changes, like CardRules class and ai hints, otherwise the project would not compile.

Rob Cashwalker wrote:friarsol, I see the value in the Forge Workshop as an answer to the many requests for easy addition of custom cards and sets. While the remaining cards aren't scriptable (yet) there will always be new basic cards that can be handled easy by nearly anyone.

Hear, hear!
Who hasn't at least at some stage dreamt of making their own Magic sets? And since R&D jobs at the Wizards are not something most of us can realistically even dream of, this could be an interesting alternative. Develop your own cards and sets - and actually play them!
There already are free tools that let you visually design new cards (I've used Magic Set Designer), what we've been lacking is being able to play them.

Yes, I confess I've been toying with a similar idea ever since I first discovered Forge. It seemed to me an almost logical thing to try next, after fantasy blocks. And I think there's a great potential if our userbase were allowed to develop and share their own expansions - unofficial "bootleg" MtG sets that you could play nowhere else!

So this is a definite thumbs-up for DrDev's Workshop and the possibilities it opens.
Also +1 to Rob's other points.

Rob Cashwalker wrote:friarsol, I see the value in the Forge Workshop as an answer to the many requests for easy addition of custom cards and sets. While the remaining cards aren't scriptable (yet) there will always be new basic cards that can be handled easy by nearly anyone.

I envision this becoming like an IDE for Forge cards.. Being able to manipulate all the card data graphically or textually. Click the picture to change it and set URL; Add/Remove keywords via list boxes and combo box; Ability building wizards; change set membership; add/remove/modify set data; etc.

I don't think it should be limited to dev mode or running from source, it would be better if it were an external tool. May not be easy, but with the work you guys have done to separate the other parts, it's certainly possible. (need to break out the common UI and Card db objects)

Good work drdev.

Drdev was asking for opinions from people who script cards. I am a person very familiar with scripting cards. I gave a personal opinion about why I wouldn't use it. I gave no opinion about whatever external value it might have to people who are unfamiliar with the scripting system. I tried to list some things to make it more valuable for a person like myself.

I wasn't trying to admonish set building or anything of the like. But the Workshop still has very limited added value to someone like myself in it's current form, but some of the things I suggested could make it more valuable than just a text editor. Was my criticism non-constructive? I don't believe it was.

friarsol, your feedback was constructive. It helped me see what I could do to make it more valuable to developer scripters.

That said, I also really appreciate the feedback of others like Rob and Rumble that share my vision for allowing all our users to create, share, and play custom magic sets, something that doesn't exist anywhere else.

Rob, to your point about making this an external tool, I don't see why that is necessary. That'd be like saying Deck Editor should be an external tool. A big reason I took the time to create the navigation tabs was to allow a Workshop screen to be possible within the main Forge application without having it interfere with the rest of the game. The ability to tweak cards and see the effects immediately, either by viewing the difference in the Card Details pane, or through tools I hope to build that allow launching directly into different game states to test the card, is invaluable. Not to mention how much more discoverable it is as a tab that's always available (though we can obviously add a preference to hide the tab for someone not interested in using the Workshop).

Plus, if and when we get network game support going (and maybe even before then), I hope to allow people to collaborate on sets over the internet right from Forge. This way, for example, you could work on a custom set with some friends, then challenge them to a draft using that set, all in the same application.

Obviously this all will take some time, so my first goal is to make the tool useful to developer scripters. I can then add the designer tools and other bells and whistles to make it better for designing custom cards and sets without needing knowledge of our scripting language.

All that aside, Max, I'll have to look at the changes you made and carefully reimplement the card updating in a way that respects the project organization better. I'll let you know if I have any questions.

Thanks.
-Dan

drdev, so which methods are you going to need from that PaperCard infrastructure?

Something like

Code: Select all

void addCard(String cardName, List<Pair<String, CardRarity>> editions)
void updateRules(CardRules newRules) // card will be found by newRules.getName()
void removeCard(String cardName)


?

(note: to rename a card, remove it and add under new name)

Those should work.

r23734 - CardDb.getEditor() - holds some methods to alter card database.

I'll also remove ai-hints from cardrules soon, just FYI.

CasrdScriptInfo - I suggest it should be kept next to card script editor in the gui package.
But why?
Because no other module (current game, ai or future net) would use this class, so it does not seem to belong to 'core'.

For the same reason StaticData won't hold any CasrdScriptInfo instances. That Map<CardRules, CardScriptInfo> scriptLookup would be better kept somewhere next to CCardEditor.
---
Your method TextUtil.join is a duplicate for an existing library method - org.apache.commons.lang3.StringUtils.join
---

CardRulesReader will be moved to core, but without CardScriptInfo.
Any extra data is to be received by subscription mechanism, ie when reader meets an unknown line, it sends it to subscribers, who may recognize ai hints and so on. There's also going to be a point where external files are able to observe each card parse start and finish, to fill CardScriptInfo or similar strucutres.
(Will do that by myself)

PS: Please, update your IDE settings to use spaces for identation. Here's how to do it in Eclipse:
http://stackoverflow.com/questions/4079 ... ad-of-tabs

If CardRuleReader is moved to core, can you make it so I can have it update existing rules from a new script, as it supported before? Or should I be creating a new CardRules instance whenever changes are made and passing that to a CardDb.getEditor() function?

I'm fine maintaining this dictionary in the GUI code so long as CardStorageReader remains in the GUI code to access it. Though it is going to make things trickier for building the dictionary across multiple threads.