Quick Attack!

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!

In which you'll get an opportunity to point and laugh at ugly ugly code

So I've implemented a first stage prototype (I love using those words) of the "Dependency Walker" continuous effects sorter, the basics of which I went through in the last post. So now the process will be something like:

Card tells the engine it wants to supply a continuous effect, and supplies the different parts of the effect in addition to what the entire effect(or parts of it) depends on (such as "Targets type" for Gaia's Anthem) as well as which layer each part goes in. The engine sorts those layers first by CDA-nonCDA,then by Dependency using this code below and then by timestamp (also below).
http://sharpening.pastebin.com/5PSCpt4U

NOTE: That I still think I have some corner cases to handle, but the principle will be the same.
EDIT: Of course, there's also the rather BIG corner case (:P) of having no circular dependency, in which case the walker shouldn't be used at all. Fixed.

The roots kiss the sky and the crown bites the dust

I bet alot of you who read my second entry on this blog chuckled quietly to yourself. "Oh, he'll feel the pain of actually trying to *implement* a continuous effects system with dependencies soon enough." :P Well, if you did, you were right. Dependencies are beating me up, though I have made some headway. The tracking of their dependency wasn't the problem, that works in theory (everytime I say something works, you should probably add "in theory" because until I start prototyping cards I can't actually test anything),the problem is of course comparing the dependencies/targets and sorting accordingly.

In addition, I must be able to weed out circular dependencies and apply those effects in timestamp order instead. The idea I have so far is:

1. Determine all dependencies for all effects. That is for each effect E: Loop through each other effect F and if that F's target field is in E's list of dependent fields, add E to F's list of dependants and F to E's list of dependsOn. To represent this visually, it kind of becomes an "upside-down tree structure" (Damn language difficulties).
2. While there is an effect E with an empty dependsOn list, add E to the final list of Effects for the layer.
3. (This is the part I'm wrestling with currently.What we have left is a bunch of effects that all depend on one or more of the other effects.) What I'm pondering is designing a sort of recursive function "tree walker" that will traverse the tree and mark each effect it passes as visited and branch for each effect the current effect dependsOn and if a branch returns to a previously visited effect before reaching a leaf(an effect that no other effects dependOn), all the effects it visited will be part of a dependency loop and should be added to the final list of Effects in timestamp order.
4. If there are still effects remaining, go to step 2.

This sorting WILL be expensive but probably has to be done everytime a continous effect is added/removed.

Thank Urza I have other things to do to clear my head! Costs are now mutable and Activatables have been restructured to further simplify "cast without paying". Now you cannot create your own Activatables anymore, you have to go through the ActivatableFactory and get a "Base Activatable" that only handles the cost payment(s). Then, you append the desired effect to the base activatable. The reason is that this way I can depend on payment being the first effect listed and as such, skip it everytime cast-without-pay is needed. Now to figure out how conditional cast-without-pay will be handled there. (Traps).