1 Introduction
Currently, there is no free, open source proper alternative to Magic Online. This makes it hard to play for many people because the cards are extremely expensive or simply unavailable in many countries. Currently, to the best of my knowledge, the best free but not open source program out there to play MTG in is Magic Workstation. However, this program is outdated and haven’t been updated for many years, and the original coder refuses to release the source code to the community. There is a community around the program that maintains the central database file and releases HQ scans of the sets as they are released. It would be wise if one could use this resource in a new program.
1.1 Outline of the program
A program is to be coded that is free (as in, free beer), and open source that allows people to play MTG over the internet for free. The card images are to be loaded as MWS does it, and the database should be able to more or less automatically work from the official database (Oracle). The program should support various alternative play modes such as FFA and 2v2, rather than being limited to 1v1 as MWS is.
1.2 Name
A name is not yet chosen for this program. I have thought of various names similar to other free and open source software:
- Free Magic
- Open Magic
- Magic forever
- Magic for everyone
Ideas are welcome. I think that an official name should be decided by the community in a semi-democratic fashion if there is enough interest in this project.
1.3 Coding language
A suitable coding language is chosen. I am not an expert on that. A cross-platform language is a necessity and one that works in a browser would be neat. Altho perhaps it would be too laggy to run in a browser. I have no knowledge about this.
2 Development
Full automatization is sought, but is added along the way. It is not necessary to have full automatization immediately for release. It is important to get the basics down correctly, then the automatization process can begin. This is similar to how it went with MWS which has a small amount of automatization such as clicking a bottom to untap all cards that one control.
Below I gave my ideas for a development time-line (without times, but in chronological order).
2.1 The board and board zones
The first thing to be made is the playing board. This is basically just one huge square or rectangle where everything is on. The board is then divided into different zones that correspond to the MTG zones; player_n hand, player n_library, player_n exiled etc. These zones should be able to have properties. For instance, the hand zone is normally only shown to the player who the hand belongs to but this may change with some cards (e.g. Telepathy). Different zones may have only a limit number of cards. For instance, the library and graveyard zones may only have 1 stack of cards but may have an unlimited number of cards in that stack. The cards in the hand zone cannot be stacked but can theoretically be infinitely large. Rules for handling discarding cards are added much later. First it is essential to get the most basic things working so that one can begin using and testing the program.
The layout of the zones on the board is chosen by the host. See 2.3.
2.2 Cards
Cards are displayed via their pictures in miniscule format just like MWS. Customizable size for the cards is a good idea and should be added if possible. It should just be a matter of scaling. If there is no picture for a given card, a mechanism similar to the one in MWS can be used, i.e., auto-generate a pseudo-card based on information from the card database.
Cards should also be able to have properties. This is important for card ownership, control, status of being flipped/rotation (both vertically in case of flip cards from Kamigawa and cards played with the back-side up from various sets, and recently, double-faced cards from Innistrad), number of counters (including type) on the card, card color, card type etc. Some of this information can be copied from the card database.
Cards should be loaded from a suitable deck file. The program should support the various deck formats that exist as it cannot be hard to convert between them there is no reason to prefer the one or the other.
The player who controls a card which is on the battlefield should be able to move it around on the board as he pleases. When the game supports this along with different zones and stacking cards in the right zones etc., then the game is basically playable.
In the default settings, it should be shown to players how many cards there are in each of the zones, even those that the other player controls/owns. I say default because some custom format may change this (or potentially, a card, but I’m not familiar with any card that has an effect like that).
2.3 Networking and multiplayer
MWS is limited to 2 players. There is no need for that. The game should support pretty much any number of players. I have limited technical knowledge of how hosting should work. The way MWS does it seems okay to me, that is, one player hosts a server and other players connect to it via IP addresses or via searching via a central server. This requires some set-up as the host needs an open port. If possible, a fix to that problem should be found. Perhaps via some virtual-LAN solution similar to Hamachi. However, initially, the simplest solution should be sought. Then work can begin later on an advanced solution.
The layout should be customizable so that one can play a variety of game formats. There is no reason why people should not be able to play some custom designed game format that they like. This will also promote creativity with game formats. In the long run, it should be made possible for people to design their own game formats so that the work burden is as much spread out as possible.
The reason more than one format is necessary is that the zones are not placed identically for FFA as they are for 2v2 or 2v1.
Some other things like players’ lives remaining, total life, poison counters and later, mana pool and priority should be added now.
2.4 Automatization
Now more automatization can begin to be implemented.
2.4.1 Simple automatizations
The first automatization that should be implemented is the simple kind that is in MWS. This includes bottoms for untapping all cards that one controls (excluding those marked with the property “Does not untap as normal”).
2.4.2 Slightly more complicated automatizations
The next thing that is necessary to include are slightly more automatization such as universal and conditional (“all zombies”) +1/+1 power/toughness adjusters. It is important at this stage that such mechanisms should be able to be able to be disabled in case there are special circumstances or the program gets it wrong.
I can think of two ways that one can make more automatization:
- One can write a lot of clever code that recognizes and interprets the cards using the Oracle database and then enforces those in the game automatically. One can write such a code but it is a lot of work. However, one can begin with the simple stuff, such as automatic combat damage assignment. I think it is not too hard. This is a top-down approach.
- One can make a subprogram that lets users tell the system how a particular card works with some kind of specialized code. In this way, one can simply have people writing all the necessary code for each card and collect it. Some selection is necessary as some people get it wrong either deliberately or accidentally.
Perhaps some combination is possible. In any case, it is definitely possible.
2.4.3 Towards full-automatization
From the above, it is just a matter of working towards full-automatization. I think that with a large number of people, it should not take long to have most cards understandable to the program.
I expect a lot of finesse problems with things such as priority, responding, and the stack, but nothing that is impossible.
