Normally Michael contributes to the SCG community in the form of Magic art critiques. Unfortunately, since Wizards has not given him a flying bear with great art lately, there have been no critiques from him for a while. That does not mean he has abandoned Magic. In this article Michael switches gears on us and makes a case for the inherent strengths present in the mechanical game design of Magic.
Have you ever stopped and wondered what makes Magic such a great game? To some Magic is a game of strategy that satisfies their competitive impulses. Others enjoy the social aspect, having made many great friends through their years of playing. No doubt collectability plays a role in its appeal. I enjoy getting together with my buddies for multiplayer – Magic is great for weekly guys’ night. Some people even enjoy the game for the artwork on the cards. I have even heard that there are those who see Magic as a stepping stone to fame and fortune in Poker; go figure.
This short list of reasons is not comprehensive by any means, and the factors cited are not mutually exclusive. We all have our reasons for liking the game. But I am asking a more fundamental question.
What makes Magic a good game?
I contend that Magic is a good game because, on a fundamental level, it adheres to the sound principals of software engineering that are embodied by Object Oriented Programming, or OOP for short. Furthermore I believe that as long as Wizards maintains the game consistent with the OOP model, they will most likely be able to keep Magic viable well into the future. There is a danger though, that in trying too aggressively to”open up design space” for future growth they may abandon the OOP model and inadvertently undermine the game system.
To support my comparison of Magic to OOP let me first discuss some of the basic notions of software design.
Generally speaking, the software of today is superior to its predecessors as a result of more wide-spread acceptance and utilization of Object Oriented Programming techniques. The predominant precursor approach, which is called Functional Programming focused on”what a program does“, while object oriented programming concentrates on”what data does the program act upon”. At the heart of OOP are individual program components called CLASSES, which when called during the execution of a program create instances of those CLASSES – these resulting instances are called OBJECTS. Hence the name Object Oriented Programming.
The essential power of OBJECTS is that they embody the benefits of encapsulation and inheritance.
Encapsulation means that the OBJECT contains all relevant information about itself including its interface and its member functions. For context and comparison to Magic, think of a popular card such as Serra Angel – Serra has interface attributes such as a mana cost of 3WW, a power of 4, toughness of 4, and has the special ability (or a MEMBER FUNCTION) of”does not tap to attack”. Often such an ability or function is communicated in the text box in the form of a keyword mechanic such as”this creature has Fear”.
Inheritance refers to the characteristic of an OBJECT that says it can derive additional key information from a higher order PARENT CLASS. Again using Serra – since Serra is a Creature she INHERITS all the attributes that befall creatures in general such as possession of the functions (or abilities) of”can attack” and”can block”. The efficiency gained here is that all those basic creature attributes do not have to be written in the text box for each creature ever developed. By simply declaring the type of the card to be ‘creature’ the card gets all of the PARENT attributes and functions without cluttering up the text box. This is a key strength of Magic’s implementation and is fundamental to the viability of the game.
The overall result of the paradigm shift towards object orientation is that, when properly implemented the OOP approach produces software that superior to functionally focused software in terms of portability, maintainability and expandability. It is only the latter two of these attributes that are most relevant when discussing the positive influence OOP can have on the longevity of Magic.
Maintainability of a program comes into consideration when problems are discovered in usage. Maintainability addresses the ease with which those problems can be fixed once they are discovered. Usage of CLASSES, which embed the relevant member functions at the OBJECT level rather than the OS level promote maintainability by localizing the extent of change.
To illustrate maintainability in the context of Magic note that Wizards”maintains” the game in two ways. First the DCI maintains the game for tournament play when they update the banned and restricted list – when they do so they are maintaining the game at the object level. A good example of this was demonstrated in Urza’s Block when Memory Jar was banned. Since the offending mechanic of excessive card drawing ability was implemented at a low level, i.e. on a single card, it was easy to fix the overall format by simply banning that one card. If on the other hand all artifacts in the block had been given that same ability, then the problem would have been much more widespread and harder to correct within the block.
A second type of maintenance is also employed by making changes at the level of the core rule set. A recent example of this type is the re-write of the Legends rule. This change was done in order to”fix” the old rule, and to open up design space for development of the Legends-heavy, Champions of Kamigawa block. I believe that this particular change was not required to accomplish the behavior that they wanted in ChK; more efficient solutions could have been implemented at the OBJECT level without tampering with the behavior of the old existing Legendary cards. That however would be a different* article.
Expandability addresses how easy it is to add new features to the software in subsequent development. Poorly designed software often is not amenable to growth due to sub-optimal choices made during initial development. OOP techniques attempt to make software more expandable. Companies that make money developing software like the idea of promoting expandability. By adding some new features and rolling the version number they get to sell an upgrade to their existing customer base.
Making software expandable as part of its initial design is preferable to starting from scratch each time a new version is slated for development. As consumers we know how we clamor for the latest and greatest version of anything; it is human nature to want the latest and greatest – we have to have it, and we have to have it now! Witness the anticipation we experience while we wait for each new expansion of Magic. It is just good business for the producing company to build in ease of expandability into their product line.
While the attributes of portability, maintainability and expandability are desirable, they are just fortunate by-products of the higher OO goal of providing for re-use in programming. The main reason to pursue OOP is to create a library of functions which can be easily tailored and re-used. The impetus for re-use is that software development is very expensive in terms of the cost of labor. The OO economy is that rather than write custom code for every application, it is advantageous to spend the energy instead on creating general, customizable program components that can be readily pulled off the shelf and tailored.
The basic card types of land, creature, artifact, enchantment, instant and sorcery are the fundamental re-usable CLASSES of Magic. The customization typically comes in the form of establishment of new keyword mechanics (analogous to new MEMBER FUNCTIONS) that are communicated to the OBJECTS in the text box on the card itself. Wizards, whether conscious of this similarity to OOP or not, has in fact been very successful so far using this model for development to the benefit of the game. As such I think the approach has enhanced both the viability, and the foreseeable longevity of the game.
Having introduced some of the building blocks of OOP let’s now look at how the paradigm is implemented on a computer system. Typically a computationally based SYSTEM consists of a CPU which hosts an Operating System or OS for short, such as Windows or Linux. The OS provides the rules for utilizing the resources of the system such as the access to memory and the execution of instructions which are provided by the application program. The OS also manages the user interface which typically comes in the form of the keyboard, mouse and monitor. Think of the OS as the large-scale context and the governing rules of the system.
The program manifests itself in a series of overarching instructions which are executed by the CPU in accordance with the rules set forth by the OS. These instructions, in the form of a program called MAIN, call other subprograms in order to accomplish the goals of the system. We have now come full circle because the subprograms that are called are in fact the CLASSES that were described earlier.
Switching now from discussion of design considerations to the dynamics of game-play, we are at a point where the comparison really becomes interesting. When you sit down to play a game of Magic the most important piece of equipment you bring, aside form your deck, and is (for better or worse) your brain. Your brain is the CPU. Your deck is your primary resource that contains the basic CLASSES you have chosen to employ in the game. Again, your deck behaves in the role of the SYSTEM hard-drive. You literally draw from you deck in accordance with the rules of Magic. Those rules, which you ideally have memorized, and are therefore resident in your CPU, have been developed by Wizards, and they are called 6th Edition Rules. The zones of play such as the in-play zone and the graveyard zone are equivalent to RAM which is dynamically allocated.
As an aside, don’t underestimate the great benefit to the game realized by the upgrade of the rules to their 6th Edition form. In my opinion, establishment of the 6th Edition rules was the single most impressive accomplishment in bringing Magic into closer alignment with the OOP paradigm. Prior to that point Magic was very quirky, fraught with arcane timing, and vulnerable to confusion due to many factors. Adaptation of such computer-centric terms like”the stack”, and the introduction of an orderly succession of priority and timing immeasurably improved this game. Overall, the advent of 6th Edition made Magic more computer-like, and in particular made it more Object Oriented – although it may be a rather bold statement, it probably saved the game from extinction.
As you sit across the table from your opponent in a duel, it is your SYSTEM against their SYSTEM. Based on the flexibility you have built into your deck construction you create your MAIN program on the fly. In other words you decide what to do depending on what you have in your hand, what the board position dictates, and on what resources you have at your disposal.
The act of drawing seven cards at the beginning of the game is a form of INITIALIZATION (another programming term, although not exclusive to OOP) which fills your BUFFER (in this case you hand) with playable options. You wait for priority to cast a spell which is equivalent to calling a CLASS. Prior to casting the spell you pay all related costs, essentially dedicating your system resources to the task, and then you declare the spell which puts a copy of the corresponding pseudo-spell on the stack. This action is equivalent to creating an OBJECT which then stays on the stack until its conditions for resolution are met, or until your opponent interferes with its resolution by casting counterspell for example. If your spell resolves, the card, which represents an OBJECT, thereafter remains in play having been allocated space in dynamic memory. While in play the card reminds you of its ATTRIBUTES and MEMBER FUNCTIONS which you can employ to your advantage in the game as long as you continue to observe the rules put forth by the OS (6th Edition Rules).
The structure of each player’s turn is organized according to the rules; players have main phases, they cast spells of all types, but only in accordance with applicable timing rules (one land per turn, sorceries only during main phases, etc…) – players have combat phases, etcetera… Creature OBJECTS interact with one another in combat as attackers and/or blockers and damage resolves; if a creature OBJECT sustains lethal damage it is removed to the graveyard and the corresponding MEMORY is freed-up for reallocation as perhaps new creatures enter play.
The previous paragraphs have provided a summary of the major ways in which Magic is similar to OOP in terms of design and game-play. Most likely there are many more ways that could be cited. That may be all well and good from an academic perspective, but where does the discussion lead us practically speaking?
I believe that a major benefit of the comparison it that by understanding and appreciating the benefits that Magic derives from use of OOP principals it will help us become better consumers. We will be better able to evaluate Magic design changes – more accurately evaluating whether a change has been made in a good or bad way. Making an argument that a change at the OS level is not as efficient as making a fix at the object level, when properly articulated will be much more persuasive that simply saying”…I (do/don’t) like the change; it is (in/out) of flavor…”.
In summary, Magic is a great game.
Magic is maintainable and expandable, and enables extensive re-use of the key card-types, or the CLASSES and their corresponding OBJECTS that are fundamental to the game.
Each new block expands the game by adding new cards and by introducing new mechanics. It is the very fact of this expandability that keeps Magic fresh and dynamic. Until I decide that I have enough new cards to last my lifetime I would like to see Wizards continue to succeed in producing this game. To help realize that objective, I believe that Wizards should embrace and promote the similarity of their design process to the OOP paradigm – following this method in the past, whether consciously or not, has improved the viability of the game and has contributed to the staying power that it currently enjoys. Continuing this philosophy will contribute to the overall longevity of the Magic: the Gathering.
Michael Jay LaRue
Legendary Engineer Legend
[email protected]
* – A follow-up article to make the case as to why the Legends change was a bad idea might be forthcoming. At the center of my concern is that this particular change departs from the efficiencies of a more OOP-compliant, object level solution. Changing the OS before seeking a better solution at the object level is bad for the future of the game. But like I said, that would be a different article.