
The last choice is where I am struggling right now. I can’t see the whole project in my head. I’m trying to be agile and only program what I immediately need. MTG Forge 1.0 did help me see many aspects of the overall design that I did well and those that need improvement. MTG Forge was written before planeswalkers but it was flexible enough to incorporate them. (Although the program presumes your opponent will only have one planeswalker in play.) The file “cards.txt” was extremely useful for adding creatures with keywords like flying and haste. The “Generate Deck” option was a great success and I hardly ever use the deck editor any more. If I want to exercise my deck building skills I use the sealed deck option.
It is dangerous to talk about one’s weaknesses, since they usually outnumber the positive, but I’ll give it a shot anyways. People’s number one complaint about MTG Forge was the user interface and I understand where people are coming from. Personally MTG Forge’s biggest weakness was my cut-and-paste mentality when it came to programming cards. The amount of redundant card code is enormous. I plan to use the Factory pattern in order to centralize code like “choosing a target player” and “dealing damage to a creature.” In the back of my mind are hard cards like Searing Meditation (when you gain life you can pay 2 and deal 2 damage to a creature or player). Cards like that can only be programmed if all of the gain life code is in one place. (A better solution might be to observe a change in your life points instead of adding Searing Mediation to the life gain code.)
So what does all of this have to do with over engineering? Well you try to make really, really good design decisions in the beginning, so you don’t regret it later. I may never actually program Searing Meditation, but I want that level of flexibility. The best way to keep things flexible is to make each component only dependent on itself. The main parts of MTG Forge 2.0 will be Card (all card code will be handled here and could be used in other Magic projects), GUI (the user interface will be totally separate), Input (it handles all of the mouse actions like choosing targets), and the Engine (does things like lets a user draw a card, determines the winner or loser, and checks for creature damage).
I’m going to tell on myself, but my worst offense is probably global variables. They keep track of all player zones and life totals. (Everything that begins with AllZone is a global variable.) They are also cause MTG Forge to get slow after a few games since the stack of all the method calls keeps getting longer and longer. The Engine part of MTG Forge will replace the need for any global variables.
Hopefully I haven’t been too long. –Forge