Every version of Forge comes with the file “changes.txt” which describes some of the changes.
Unfortunately changes.txt is extremely brief and full of jargon.
Today I thought I would decode changes.txt and describe some of the changes in common English.
First a little background info. In Forge cards can be encoded in one of two ways: Java or scripted. A Java card is in regular Java and you can see everything that is going on. A scripted card uses only text. Scripting is one of the reasons that Forge has so many cards, scripting saves a ton of time versus coding in Java. The “script” for Shock looks like this A:SP$DealDamage | Cost$ R | Tgt$ TgtCP | NumDmg$ 2 | SpellDescription$ Shock deals 2 damage to target creature or player.
From changes.txt, “Rob added code that can display different images for cards that are included in multiple sets.” Going back to Shock, which is in /res/cardsfolder/shock.txt, I can see 8 different card pictures that are downloaded for Shock. Unfortunately, as of right now, you can’t specify which Shock card picture you would like. (On a side note, I didn’t deal with “set of cards” in Forge because I had a hard enough time getting stuff working. As Forge has gotten bigger, the issue of “what set is this card in?” becomes more important.)
“Sol added code that gives us and the computer access to the other phases that were missing in earlier versions.” This change is pretty easy to understand, now you have access to all of the phases in Magic, woot!
“We are currently in the process of creating a new AbilityFactory system which is designed to replace many of the scripted keywords.” The scripting code has become messy so they are refactoring (moving) the code around in order to make it cleaner. Cleaner code is much easier to deal with, so you don’t feel like pulling your hair out.
“Moved majority of discard code to Player classes.” Initially Forge didn’t have a Player class. A player was specified using only a string, “Human” or “Computer”. This is why Forge sometimes says “Human draws a card” instead of “You draw a card”. Since Forge has grown, creating a class to represent a player has become more important. Instead of the discard code being separate, now it is part of the player class. I presume you, the human player, and the computer have different player subclasses but I’m not sure.
“Fixed null-pointer error for non-Targeted Fetch cards played by the AI.” As a Magic player you know that your brain automatically looks for the word “target”. Many cards aren’t targeted and they have to be handled a little differently. Apparently the AI caused an error when it used certain types of cards. (Null errors are the bane of programming. Every programmer has encountered them zillions of times.)
“Convert Library of Alexandria, SearchMerc/Rebel to use abCost and Target.” Many of the changes involve removing the Java code for a card and replacing it with scripting, which is a good thing because this actually reduces the number of lines of code. This is the script for Library of Alexandria
A:AB$Draw | Cost$ T | NumCards$ 1 | ActivatingCardsInHand$ 7 | SpellDescription$ Draw a card. Activate this ability only if you have exactly seven cards in hand.
“Mishra's Factory now uses AF_Pump.” Java code replaced by scripting again. Mishra's Factory lets you pump up another Mishra's Factory that has become a 2/2, so that ability is now scripted.
A:AB$Pump | Cost$ T | ValidTgts$ Creature.Assembly-Worker | NumAtt$ +1 | NumDef$ +1 | SpellDescription$ Target Assembly-Worker creature gets +1/+1 until end of turn. | TgtPrompt$ Select target Assembly-Worker creature.
“Goldmeadow Lookout, Oran-Rief, Magosi updated to use Ability_Activated.” Before Goldmeadow Lookout didn’t use the Java object Ability_Activated and now it does. Many times I would cut and paste code instead of making objects and central points of control.
“Fix for cards still using Input_NoCost_TapAbility.java. This same fix may be needed for other Inputs.” Activated abilities have a ton of different costs and some activated abilities costs only tap a card. Input is how Forge processes all mouse input. Input uses the State Pattern.
“Modular Targeting now should happen as the Modular creature goes to the grave instead of on Resolution. This fixes the Input issue that was occurring due to the Phase changes.” Some of the fixes in Forge are regular rules issues. You may think you understand the rules but you have to be a regular rules lawyer or a DCI Judge in order to never make a mistake.
My biggest rules mistake was thinking that there were two battlefield zones (one of your and one for your opponent) and that Elvish Piper was targeted. Obviously Elvish Piper isn’t targeted but I was used to the player always making a decision before the ability went on the stack, instead of when the ability resolved.
If you have any other questions about changes.txt, just ask on the forum.
Keep on tapping,
mtgrares
Posts
