Thanks to DennisBergkamp there is a new version of MTG Forge with 1396 cards. I'm happy to say that morph is now supported. I have also improved the AI's quest decks, so now there is a total of 23 decks with wacky names such as Frodo, Iceman, and Einstein. The deck editor now sorts faster thanks to a 2 line fix.The other new feature is that you can remove cards from MTG Forge that you don't like. MTG Forge has many cards that don't work 100%, so you can easily remove those cards. Execute "run-remove-cards.exe" and you can choose which cards that you don't want to exist. If you happen to use a deck that has any removed cards, the cards will be named "Removed Card".
MTG Forge is Java based and will run on Windows, Linux, or Mac.
MTG Forge 03-20 Download
haha, I was happy that I beat you in number of cards with my latest Wagic release (1340 cards), but I guess I have to fight again :p
ReplyDeleteThank you very much. unfortunately there is a bug with the card Shatter that makes freeze the game
ReplyDeleteYou are right! I've fixed this for the next version...
ReplyDeleteAgain, guys: Regression tests!!!
ReplyDeleteOne afternoon of code, countless debug hours spared. Do it!
mtg forge doesn't have a maintained regression bucket, but it usually only takes me about 5 minutes to debug a problem.
ReplyDelete@Anonymous: the problem is not the time it takes to debug one single error, rather making sure that new code is not breaking existing stuff, or that a bugfix is not bringing 10 more bugs.
ReplyDeleteThings such as "woops, I changed the combat damage code recently, and first strike is not working anymore" or "that bug that I fixed in previous release is back again, are you sure you got the latest version of my code ?" don't happen with a regression suite.
When people report a bug such as the "Shatter" one you just got, you write a quick test at the same time as the bug fix. It takes between 2 and 5 minutes. Then you are sure Shatter will ALWAYS work in future releases.
You have more than 1300 cards now in Forge, how can you be sure that the ones you confirmed to work in previous releases still work in this one without spending hundreds of hours playing the game ?
Let me say it another way: I can fix a bug without thinking more than 2 seconds. If the bug is fixed and all tests pass, I can commit. If some tests fail, I know I broke something and that the bug wasn't so easy to fix after all.
How long does it take you to reproduce such a bug: "if I cast Swords to plowshares on a creature with persist, the game crashes" ?
What if you decided to rewrite the entire combat system ? How long would it take to make sure that trample, banding, flying, protection, shadow, first strike, reach, double strike, etc... still work the way they should ? Isn't it exactly the kind of work that you don't want to do just because you know it would break so many things that you'd rather start coding a whole new application instead?
I hope I don't sound too rude, I've had a long day.
These are lots of regular issues that can become a real burden with such a huge project, and that are solved with a simple testing mechanism. Saying it changed my life would probably be a little over the top, but it definitely more than doubled my coding speed.
In Wagic, it takes exactly 3 minutes to test around 100 cards and most of the basic rules and abilities. And I don't even need to be around. Sure, it's not a silver bullet, there are still bugs, but at least I'm not haunted by the ones I've already fixed, so I know I'm really going forward.
I'd have to agree on this. Do NOT attempt to maintain a big project with manual tests. If you do, you are almost assured that you will release with bugs (that probably didn't exist when you first tested manually that given functionality).
ReplyDeleteIf you want to ensure quality releases, you have to integrate some QA mechanisms in there that grow with the product.
Hi,
ReplyDeleteAwesome that I finally found a nice MtG software for Mac!
However I have a question:
On what basis you add cards to the program? And how often?
I am missing so many cards from my favourite decks such as burn and goblins + many t2 cards like Hellspark Elemental
Keep up the good work!
yugular
hello, i am the first anonymous, not the second. It's une great projet et i want just to help you. i an mot un programmer, just une gamer.
ReplyDelete"On what basis you add cards to the program? And how often?"
ReplyDeleteThe answer is very randomly. Usually we try to add whatever cards that we can but we can only add "simple" cards. Although I am very happy to say that we have planeswalkers, exalted, first and double strike.
I'm glad that my program runs on Mac. Everyone needs to play Magic, even Mac owners.
ReplyDeleteTesting is a hard but interesting subject. Hard because MTG Forge's architecture doesn't support testing but we all know that testing is important.
ReplyDeleteThe truth is that this is a free project that is done in our spare time and while it doesn't always work 100% it is still very impressive. Although I'm glad willow and his Wagic project supports testing and has a great many cards.
Willow, regression tests sound like a great plan, and I agree with you, we should plug them into MTGForge.
ReplyDeleteBut to be honest I'm not sure how to implement them into the current architecture :(
@Forge and DennisBergkamp.
ReplyDeleteHere are the steps I took:
1) Implement an AI vs AI mode. i.e., make sure that the game does not rely too much on player 1 being human
2)create a "TestPlayer" class that will inherit from the AIPlayer class
3)Whenever the TestPlayer class needs to play, rather than calling the AI regular methods, read the action to perform in a text file
4)The TestPlayer class has to be extremely simple, to ensure that it does not influence the behavior of the game (i.e. the state of the game while testing should be as close as possible to the state of the game when playing). What I do is calling the most upper level functions. In forge, it could probably be simulating clicks on the interface.
Only point 1) is a bit difficult I think.
That's pretty much it. If I have time I'll have a look at Forge's source to give you a more specific answer.
Most interesting conversation here to date. :)
ReplyDeleteI agree that testing code internally is key to getting a less bugridden better quality program but I question whether those methods listed will even work with the current code.