The better news is that there is apparently some merit to the model because it is similar to what silly freak (Laterna Magica, link in the sidebar) is doing, only less advanced as he is generating his abilities straight from parsed Oracle text. Go check it out!
Sunday, October 30, 2011
Sunday, September 4, 2011
If a change is major enough at this stage of a project, I sometimes just knuckle down to reboot the entire thing to have an easier time incorporating the change. Looking at my projects folder, Sharpening has undergone 4 of those reboots.Unless I am misremembering, the first time was when I added the provisions for text-altering spells (Artificial Evolution and the like), the second time was when Activatables took off, and the latest time(a week or so ago) was when I discovered that I was actually reinventing the wheel by rolling my own "Treat C# as scripts" solution for the cards.
I now make use of the excellent CSScript library, which eliminates roughly a third of my own experimental, buggy code to load,compile and sandbox the scripts.The only downside versus my solution is that I haven't found a way in CSScript to specify multiple scripts to be compiled into one assembly but that is not a major downside, as all scripts will be sandboxed the same way and I can instantiate objects from the assemblies as I go.It's also not really the domain of CSScript, so meh.
Monday, May 23, 2011
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. ;)
Sunday, January 9, 2011
Sharpening is currently undergoing some offline experimentation with some abstractions ( to be even vaguer, they apply to what can be done ;P ), hence no activity on the SVN. It may not show on the blog, but I'm having the time of my life with this project ^^
Tuesday, November 30, 2010
Not dead. Dreaming.
So, seemingly just to spite my pledge, it turns out that even if you somehow implement every rule of Magic perfectly, with every obscure corner case handled, there must always be card-specific code. That is because there is a card that basically has card-specific rules, the comprules.doc equivalent of card-specific code.I'm talking about Rasputin Dreamweaver. I'm pretty sure it is the only card in MtG history to make use of the state based action:
704.5s If a permanent with an ability that says it can’t have more than N counters of a certain kind on it has more than N counters of that kind on it, all but N of those counters are removed from it.
So an MTG-implementation can't yet be truly without card-specific code because MtG itself has basically card-specific rules.
And before you point out Shahrazad as another card that is alone in the use of a rule, let me be nitpicky and point out Enter the Dungeon.
Just a curious thought.
Friday, October 1, 2010
Because of a job-issue (the lack of any), things have been quiet for a while. I refuse to let this turn into an emo whinepost about it, though, this is a programming blog, damnitall! Just know that I have uncommitted code working further towards modifiable costs as well as the beginnings of a UI outline.
Monday, August 23, 2010
Just a quick post to update y'all on what's going on: I'm ripping out the InputStateMachine code into a separate project for testing and ironing out design issues. Also, I'll take the opportunity to test out the UIBridge.
Though that DS sure is tempting... Damn Pokemon Pearl! Havn't been this addicted since Blue!