Monday, May 23, 2011

Write the program for me

Man, this place is dusty. Time to put it to sporadic use again!

The title refers to scripting, I'm not gonna hand over the reins to anybody! :P
Basically what I have in mind (and have gotten seemingly working great) is that cards and "Actions"(the concept of which is a WIP) is a hybrid between hardocding and scripting in that you write the cards as full-fledged C# ( I could potentially allow other .NET languages down the line) classes that inherit from a base class and you can reference and use any code exposed by a project called "Sharpening_Exposed" (How witty) . However, the card files aren't compiled together with the actual program but only when (for "Actions") the program loads or (for "Cards") when they are used in a deck. This lets you have both the code flexibility of hardcoded cards and the plug-and-play-ity of scripts.

There are some safety concerns, of course, like "What's stopping a card code from accessing the filesystem and network to steal data in a maliciously tampered distribution?". I'll tell you what: A whole lot of AppDomain voodoo that's been my headache for a while. >_> Basically, an AppDomain is an isolated area of code that operates with certain permissions. Fully trusted code can do anything, but I've taken away all permissions except code execution from the AppDomain that will run the compiled cards and "Actions" so all that happens if they try something like that is a SecurityException will be thrown.

Mind you, that's a *very* brief overview. ;)


  1. When writing free software, you are you own best audience. And whatever language you choose will be fine, yes there will be some limitations and maybe it won't run in the browser but if you are writing it for yourself, who cares.

    For awhile I've been trying to get some programming done but I don't think I've written anything in a year or so. Like most things, you and me have to sit down and write buggy, not 100% perfect code.

    Yes, you can debug it later but at first it might be a little crufty and dirty. It is just like writing a rough draft for school. There is a weird quote that I keep thinking about that seems to apply, "Perfect is the enemy of good" which means if you try to be perfect you will never get anything done, which applies directly to programming.

    Just some random thoughts. I hope you get something working.

  2. I know you are trying to implement 100% of the rules but the rules are revised every time Wizards releases another set. So implementing 100% of the rules is hard because they keep changing. If the rules never changed then that would be a different story.

    Forge does pretty good and it only implements 50% or less of the complete rules.

  3. Forge does a damn fine job of implementing the rules, largely thanks to it's flexibility from the start. What I'm trying to do currently (I just haven't written much about it) is to implement an infrastructure that will match or hopefully even surpass that flexibility.

    Oh, and I think we're above 50% now, it's just that the missing pieces are rather big ones (Damage Redirection,Part of the Layer System and such) ^^ Thanks for the comments!

  4. Incantus uses raw Python code for cards, stored in the data/cards directory, allowing the full power of Python to be applied to every effect. Like you, we ran into the problem that this allows theoretically malicious code (perhaps humorously implemented as an actual mechanic... "T, Sacrifice ~: Destroy target player's harddrive.") to be executed. Theoretically, Python can be sandboxed, but Incantus told me that such implementations are imperfect at best and that there's always a way around them, so in the end we just shrugged and decided that Incantus's audience was so small, and cards can only be executed if you put them in your cards folder yourself, so the odds of it becoming a problem in the short term were virtually nil. Of course, eventually it was hoped that the UI would be moved to a different language, for maximum graphical capability, and it could simply use a special Python version that wouldn't allow file access, thereby preventing malicious code from running. Maybe we'll see that sometime in 2020...