{"id":139,"date":"2009-12-23T14:25:32","date_gmt":"2009-12-23T22:25:32","guid":{"rendered":"http:\/\/magic.kevinleung.com\/?p=139"},"modified":"2009-12-23T14:25:32","modified_gmt":"2009-12-23T22:25:32","slug":"magic-the-language-by-rj-w","status":"publish","type":"post","link":"http:\/\/magic.kevinleung.com\/?p=139","title":{"rendered":"Magic: The Language by RJ W."},"content":{"rendered":"

(This was one of the most interesting papers I saw, not only for the thought put into it but also for topicality. In it, RJ discusses what would happen were a programming language created to model Magic. Of course, programs that can play Magic exist, such as Modo or Duels of the Planeswalker. All of these, however, implement Magic using java (such as Forge), potentially with the card info in XML format (such as Wagic). You can see a couple different approaches in a great series of posts over at mtgrares<\/a>, but RJ offers another look at how it might be done)<\/em><\/p>\n

I\u2019ve been especially impressed this quarter with my class on compilers \u2013 a system that initially seems so simple can easily reveal many layers of complication underneath.\u00a0 Magic is no different, it is a game whose basic rules can be explained in a matter of minutes (as shown in class) but the deep technique and strategy is much more far-reaching and deep.\u00a0 Thus, given these two systems, each of which is far more complicated than it seems, it was only natural that I wanted to combine them both somehow for this project.\u00a0 Unfortunately, compiling magic is rather useless without a language to compile, so I began to wonder what designing a programming language explicitly for magic would take.\u00a0 This paper discusses a possible approach to creating a programming language representative of Magic.<\/p>\n

There is no shortage of programming systems in existence today that model magic.\u00a0 Some are rather basic, in order to accomplish a specific task (such as the example Kevin presented in class), whereas others attempt to model the entire game.\u00a0 In every case, the game is modeled using an existing programming language, such as C++, Java, or XML (for data representation).\u00a0 These are not simple representations.\u00a0 For example, consider cards that fundamentally alter the rules of gameplay (Necropotence, anyone?).\u00a0 How is it simple to change the rules of the engine that runs the game?\u00a0 Creating and battling creatures is simple enough, but when spells with complicated or unusual abilities are played, it\u2019s difficult to alter the engine running the game.<\/p>\n

So, if we\u2019re to design a language, let\u2019s start with the basics.\u00a0 The important objects will have to be cards, which can be objects as in any other modern object-oriented language.\u00a0 Decklists will serve as input to the program, as these allow a game to be run between two players, but since the game is part of the language itself, there is no need to model the game playing engine at all.\u00a0 The game is run by the compiler, which when given two decklists as programs can compile an executable that simulates a game.<\/p>\n

Since cards themselves fall into a limited number of basic categories, these can serve as the keywords for each object.\u00a0 An initial list of creature, instant, sorcery, land, enchantment, and equipment will suffice for now.\u00a0 Creatures will contain two attributes: power and toughness.\u00a0 These can be set as integer values directly, or in the case of certain cards whose power and toughness change depending on the state of the game, methods which calculate the power and toughness appropriately.\u00a0 Creatures can also have zero or more attributes, such as Flying, Vigilance, Shroud, etc.\u00a0 Again, since these are language components, there is no need to write any additional code to handle these abilities, unlike existing systems.<\/p>\n

Perhaps the most interesting aspect of any permanent, including creatures, lands, and enchantments, would be the abilities.\u00a0 This is a list of activated and triggered abilities, which will act like the attributes on each card object.\u00a0 Most abilities have two components: The cost or reason for why the ability would be activated, and then the result or action of the ability.\u00a0 Given the appropriate encoding, any ability could be added in this way, since the environment is created and managed by the compiler for the language.<\/p>\n

For other spells, a more advanced system would be needed.\u00a0 Lands are relatively simple, only requiring an abilities list in the same way creatures do.\u00a0 Enchantments only require what they enchant: for example, a regular enchantment is just a permanent, but other enchantments can attach to other permanents.\u00a0 Equipment will contain a unique field that specifies the cost to equip the item to a card, then just an abilities list.\u00a0 Instants and sorceries are similar, but different, as they contain a single ability that is the result of the action.<\/p>\n

This establishes the basic structure for all the types of cards in the system, but it does not establish the most fundamental part, which is the encoding of abilities.\u00a0 The critical feature here is that abilities can alter fundamental rules of the game, and the game needs to continue to operate correctly.\u00a0 Given that there are virtually an unlimited number of abilities that could be encoded, it is impossible to describe all of them here.\u00a0 Some of the potential options will be described, but given that there are almost ten thousand cards in existence, it would be unfeasible to try to describe all the potential cards that have been created.<\/p>\n

First, consider a common ability keyword: target.\u00a0 This keyword is found almost everywhere in Magic, and provides for the ability to direct the effects of a card to a specific location or group.\u00a0 For example, \u201ctarget player\u201d selects a single player, \u201ctarget creature\u201d selects a creature.\u00a0 If an ability is targeted, we can introduce a keyword to carry out its effect.\u00a0 The language of the game will likely grow to include hundreds of keywords to specify all the potential abilities, but this is one critical item.\u00a0 Other critical encodings would be life totals, players, and permanent typing, which could be accomplished via the card type system described earlier.<\/p>\n

I deliberately avoid offering the encodings for cards, as the vastness of the game necessitates that each card could require a new keyword for the ability it specifies.\u00a0 For instance, consider the landfall ability introduced in Zendikar.\u00a0 When implementing a compiler, the designer has a choice as to whether to include this keyword in the language, or to introduce a new keyword, or to encode the ability using the existing framework (trigger land battlefield).\u00a0 Thus, given an appropriate set of triggers and a large enough language, there would be no need to encode new abilities as keywords in the language, or if they were, it would be trivially simple to add a new dictionary of these to lookup.<\/p>\n

There is no correct or best way to describe Magic programmatically, however these are some key decisions required when creating such a system.\u00a0 The idea is that it becomes simpler to model if the game is abstracted away from the programmer, who is given a language powerful enough to create an entire game.\u00a0 With this ability, Magic can clearly grow as a game, as the compiler for this new language is generic and extensible enough to allow for the creation of new features and attributes without fundamentally changing the language itself.<\/p>\n

Appendix<\/a> – includes example of what it might look like<\/p>\n","protected":false},"excerpt":{"rendered":"

(This was one of the most interesting papers I saw, not only for the thought put into it but also for topicality. In it, RJ discusses what would happen were a programming language created to model Magic. Of course, programs that can play Magic exist, such as Modo or Duels of the Planeswalker. All of […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[15],"tags":[],"_links":{"self":[{"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=\/wp\/v2\/posts\/139"}],"collection":[{"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=139"}],"version-history":[{"count":1,"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=\/wp\/v2\/posts\/139\/revisions"}],"predecessor-version":[{"id":141,"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=\/wp\/v2\/posts\/139\/revisions\/141"}],"wp:attachment":[{"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=139"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=139"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/magic.kevinleung.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=139"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}