Cards!Gamemat!Action!

So the Action-mockup is taking shape, it only took several weeks. >:/

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!

Round Reinvention

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.

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. ;)

Offline Experimentation

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 ^^