Wednesday, December 30, 2009

How to Conquer the Complexity of Rules - Part 2

The idea of putting all of the rules into one large object, RulesEngine, is very versatile. To begin with I can code simple rules and then update them later as needed. This avoids the problem of overanalyzing the rules because you want to your program completely correct which usually results in "analysis paralysis". This approach doesn't work because the rules are too big and your brain is much too small.

While having one massive object is bad in some aspects, the positives include having all of the rules confined to one location. Internally I can restructure it as often as I need to because the external methods for RulesEngine won't change. Since RulesEngine implements every single rule, I should be able to easily implement new rules and to fix rules that I have misunderstood. I can write a very simple mana pool and then later make it more sophisticated.

The goal is to give RulesEngine all of the information and let it internally implement the rules. The hard point is giving RulesEngine "all of the information" because different Magic cards need to know different pieces of information. There will always be weird cards that require off-the-wall” information like Imperiosaur which has the static ability "Spend only mana produced by basic lands to play Imperiosaur". Or cards that require snow mana or cards that say something like "you can only use this mana to pay for artifacts".

Obviously implementing Magic isn't easy but by putting all of the rules together will make the coding as easy as possible.

15 comments:

  1. You can both get rid of the negative and keep the positives that you mention by doing things another way: keep the rules in a separate library that the frontend references/use a "bridge" kind of class that the UI places all of it's calls to and routes them to the right place.

    ReplyDelete
  2. that's what I was going to mention. What you'd need is an interface that the UI is calling or anything else for that matter. That way you don't expose the implementation so the UI guy doesn't have to know how the business rules is setuped. Then inside your business rule can have a nice architecture that you can change chunks without having to modify the UI

    ReplyDelete
  3. Yes separating the "rules engine" from everything else would be very good. I try to break down components until they are easily managable.

    ReplyDelete
  4. However, some basic complexities of rules have to be implemented more or less from start.

    No free program I know about has implemented Artificial Evolution, for example. That one is something that probably needs to be taken care from the beginning.

    ReplyDelete
  5. Yes some rules have to be implemented at the beginning like a creature's power and toughness but the program need a layer system in the beginning, which GREATLY simplifies the coding.

    ReplyDelete
  6. Artificial Evolution is very definition of a difficult card.

    It says, "Change the text of target spell or permanent by replacing all instances of one creature type with another."

    Forge currently separates the text from the "real" programmed ability. The text is just a user interface graphic that is shown to the user.

    In order to implement Artificial Evolution you could almost have to generate the ability from the text itself. Since I'm starting Forge 2 from scratch I'll keep Artificial Evolution in mind and I'll try to support that (insane) card.

    ReplyDelete
  7. Marek14,

    What are 4 other very difficult cards that I should be aware of?

    I figure that I can only keep in mind 5 thorny cards. Programmers have to know how much they CAN'T remember, that is why programmers write code and documentation. Well they're supposed to write documentation. :--)

    ReplyDelete
  8. shahrazad?
    so complicated even wizards banned it. would be cool if that could be implemented

    ReplyDelete
  9. Artificial Evolution could be supported IF every mention of creature type on a card takes it into account.

    Could be done for example by making a function CType(type) which would do the following:

    If there is no text-change note on the card pertaining to "type", return "type".

    If there IS a text-change note (which is of form ["type","newtype"]), return "newtype"

    The table of changes would be updated like this:

    Every text-changing effect replaces "word1" with "word2".

    If the change table doesn't have any entry starting with "word1", add entry ["word1,word2"].
    If there is an entry ["word2","word1"], delete it.
    For each entry of type [x,"word1"], replace it with [x,"word2"].

    Of course, might be more intricate for temporary effects.

    4 cards that are hard:

    Mindslaver - if you can do Mindslaver, you will have an environment where any player can play any part.

    Bloodbraid Elf - cascade is just one of many examples of cards that allow you to cast something without paying. These tend to be quite hard for Magic programs.

    AEthertow - Copying spells is another part which tends to be troublesome. The intricate cost of conspire and support of hybrid mana make AEthertow a desirable card.

    Wilt-Leaf Liege - mastery of complex discard effects are necessary to eventual implementation of Madness.

    ReplyDelete
  10. In the current Forge architecture, Artificial Evolution and Mindslaver are indeed very hard. AEthertow tricky too, but Bloodbraid Elf and Wilt-Leaf Liege should actually be doable.

    ReplyDelete
  11. I'd keep in mind the "ease of use" of a given card too.
    It's useless to support a card that players will not use in the end if it involves too much clicking.

    I'm probably stating the obvious, but we have that kind of problem in Wagic with some complex cards.

    ReplyDelete
  12. Well, for example, when multiple abilities trigger at the same time, you are supposed to choose an order for them. Doing it every time might be a bit time-consuming - but Incantus came up with a nice solution where you get a list, and you can re-order by drag and drop and to OK it. In the 90% of cases where the order doesn't really matter, you simply get a concise report of what triggered, which is also good.

    ReplyDelete
  13. *sigh* The last comment was me.

    ReplyDelete
  14. wololo,

    "It's useless to support a card that players will not use in the end if it involves too much clicking."

    Yes too much clicking detracts from the fun.

    Marek14,

    Yes the Incantus program does many things well. I plan to copy some of its features like how it handles when multiple abilities trigger at the same time.

    "Good artists copy, great artists steal." --Picasso

    ReplyDelete
  15. Is anyone else having problems accessing the forum?

    ReplyDelete

Note: Only a member of this blog may post a comment.