Millions of Details

When writing a Magic implementation there are a million little details to keep in mind. Let’s say the user interface (UI) shows the mana cost of all the cards, but some cards reduce the amount of mana that you have to pay. Does the UI update all of the cards’ mana costs or does it just show the printed mana cost? For convenience the UI probably loads the card’s jpg, so the mana cost is never reduced and the player has to keep that in mind.

Cards and abilities that have “may” in them are also problematic like Dragon's Claw, which is an artifact that costs 2 and says, Whenever a player plays a red spell, you may gain 1 life. It is much easier to always have a card do something, which is what the player would do 99% of the time, but that other 1% causes much difficulty. When I code the AI for a card like Dragon’s Claw, the AI always gains life.

In a real game of Magic the player has to speak up and put any “may” abilities on the stack. But I believe the rules say that the ability always goes on the stack and the player has a choice when the ability resolves. So should a program like Magic Online put the ability on the stack or require the user to “play” that ability, thus making the user less lazy and more alert.

The main problem when programming Magic is the large volume of rules, which players internalize after awhile. The rules make programming hard, but they make the game fun.

New Version - Remove Bad Cards

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

Static Abilities as Triggered Abilities

Static abilities are difficult to implement, so today I’m going to talk about how to transform many static abilities into triggered abilities. Static abilities are always “on” and Glorious Anthem is a good example. Triggered abilities occur when the condition is fulfilled such as “When this card comes into play” such as Venerable Monk. Triggered abilities always start with “when”, “whenever” or “as” so they should be easy to identify.

First, let me briefly digress and talk about listeners and events. Usually a Magic implementation like MTG Forge has many events that other parts of the program can observe. One of the most common events is when a card is added or removed from a zone, addCardEvent and removeCardEvent.

Now that we have these two events can you figure out how to implement Glorious Anthem? Hopefully this should be easy, every time that addCardEvent triggers Glorious Anthem checks to see if you control that card and then adds +1/+1 to it.

Fortunately the above logic works most of the time but there are also other considerations to keep in mind. If you “steal” your opponent’s creature with Control Magic, addCardEvent wouldn’t trigger because the “play area” is a shared zone, both you and your opponent share the same play zone.

One solution is to have another event that only triggers when cards are added to your play area. (Your play area is defined as, when a new creature comes into play under your control.) Since many cards like Glorious Anthem care about only creatures that you control, subdividing addCardEvent into more specific events is a good idea.

Currently MTG Forge does implement cards like Glorious Anthem but they are a little slow and inefficient. If you have many Glorious Anthems in play MTG Forge will react a little bit slower because of the extra CPU time that is required. In essence the Glorious Anthem code is executed “too many times” and usually doesn’t do anything. Using triggered events for Glorious Anthem is both efficient and easy to understand.

Free Physics Games

Magic: The Gathering seems to attract lots of smart guys and smart guys tend to like (or be interested) in physics. I know of three pretty good games that use physics.

Fantastic Contraption - Your goal is very simple, build a machine (usually something like a car or tank) to move the pink piece on the left to the pink area on the right. Great fun and very addicting. I would love to code a game like this.


Crayon Physics Demo - Your goal is to move the ball on the left to the star on the right by drawing with your mouse. In the demo you can only draw squares but in the full version, $20, you can draw any shape. Very simple, but very cute also. Fantastic Contraption is probably a little better but you can play this offline.



IncrediBots - You build your robot out of parts and then you use your robot in order to achieve the goal. This is the most complicated but it seems interesting if you can get past the learning curve.

Quest Mode - New Version

Well I’m happy to announce that MTG Forge now has a quest mode. The questing is very simple and all menu based but still fun. You start out with a few cards and the more you play, the more cards you get. On easy you get more cards after every game, whether you win or lose, while medium requires that you win or lose 2 games. (I figured that players should always feel like they are progressing whether they are winning or losing.)

The Quest Mode is still very beta and many things need to be ironed out. The computer’s deck names should be like Frodo and Morpheus and the computer should use a wider variety of decks. The Quest Mode isn’t perfect but it is a lot of fun.

Download 03-16 Version

p.s.
If you are interested in improving the quest mode check out the forums, there are quest discussions going on here and here.

Random Magical Thoughts

I usually like to write about one coherent thought for about three paragraphs but I’m stumped. So today I’m going to write about two or three ideas.

First, Magic is a complicated game and trying to construct a basic user interface (UI) for it is hard. I keep thinking that I’ll rewrite the UI but I know it will be hard and frustrating since I’ve never done anything like that before. I really enjoyed the UI for the previous version of Magic Online and the UI for Shandalar was very clear and easy to use.

Basically I’m not a very visual person and I can’t tell what looks good and what doesn’t. My only hope for a better UI is to copy a preexisting one. I understand Shandalar’s UI the best but I will be doing good if I can write something that looks half as good.

Second, Java is my programming language of choice but it still gives me problems. The problem is that there are many different versions of Java which are supposed to work the same way but they don’t. The newest version of Java is 1.6, which is all fine and dandy, but the user interface looks different between 1.4 and 1.6 and I wrote MTG Forge with 1.4. (The user interface is “more white”, making it harder on the eyes.) And other problems abound, such as Java 1.4 code will compile with 1.6 if you turn off all the warnings, which is usually considered a bad, lazy approach to programming.

Third, MTG Forge’s source code is about 1.5 MB uncompressed and 271 KB zipped, which is about the size of Charles Dickens “A Tale of Two Cities”, 294 KB zipped. You might be wondering why am I comparing zipped sizes between Java source code and plain text? The answer is that if two things compress to the same size they have about the same amount of information.

I have no idea which project took longer to write but by compared zipped sizes, we know that they have about the same information. (Although hopefully my program is more interesting than an old book, but who knows?)

p.s.
Information theory is part of computer science which deals with the theory behind computers and how to code better programs.

Program Life Cycle

I’m going to be boring for a minute and just talk about plain, old programming. When you write a program from scratch it is brand new and shiny. Everything works completely as it should and it feels like a brand new card.

But any good program is constantly modified in order to add new and better features, so the program grows little hairs and feels “less new.” When a program gets into middle age it is harder to add new features because everything feels fragile. Modifications that were never intended have been grafted in, so the design is a little bit messy. (MTG Forge barely supports planeswalkers.)

After awhile, pick whatever time span that you want, the program feels old. New features are very hard to add and constantly require the programmer to “tip-toe” around the old code. Parts of the program may have completely been rewritten and are poorly documented. And overall the program feels like a 10 year old car, usable but definitely not new.

After a program has gotten “old”, it is time for a bright, shiny new version. MTG Forge has probably become old and needs to be retired. That way the new 2.0 version can have a different, improved design that fixes many of the “hacks” that were needed with the old code.

I’ve started working on version 2.0 and it is a tough beast to handle. At first I was too ambitious, but at the very least it will require a total rewrite from the ground up. Many of the ideas from version 1.0 can be applied to 2.0, but the implementation will be completely different. A plausible goal is to get 2.0 working with a few cards so that you can see progress without being completely overwhelmed.

With all of that said and done, it is still nice to add new stuff to 1.0 because it works and you can immediately see the results.