The good stuff: 

Welcome back to regular updates!  Are you excited, because I certainly am.  For all seven of you who see fit to follow the progress, take note - I'll be trying to increase the amount of updates.  Some of these updates are required by way of my degree so they'll be a bit more formulaic (such as this one) and some will purely be content updates.  But wait, I hear you cry - where are our Holiday gifts?  How about this, I'll dump an update a day for the next three days.  We'll pretend it's an advent calendar.  Normally I'd just dump a bunch of content here, but as we get closer to the 1.0 release I'd rather drip feed, so buckle up.

Okay, so wait till tomorrow for the cool stuff.  But what about this week? 

Mostly this week has been catching up to where I feel I should be, but that doesn't come without some of the more normal dev problems.  One of the elements I've really wanted to get into before the 1.0 is what I call slow-speed mode.  While I wrote most of the backend to support it ages ago, I've been dancing around wiring it up for a number of reasons.  I had this gloomy suspicion that it wouldn't be easy to get working no matter how much prep-work I put in, and although it's half way to  done, my fears have already matured.  Originally I was simply iterating over all cards on the board at once, during the AI turn.  There were two major elements required to facilitate slow-speed mode: 

• The cards needed to be "sorted" in any specific order so they would run in a reasonable way that could be comprehended by a player
• The cards need to run individually, AND finish moving or drawing any effects to the screen prior to kicking off the next card in the order.

I solved the first requirement prior to the holiday break (though I won't say no sweat.)  It was one of the driving forces behind completely rewriting how cards were stored.  The second one is what I've been putting off.  It's not taxing conceptually but it's already annoyed me enough to be written about.  My first play was absolutely lazy in it's conceptual execution.  Just slip the whole AI turn into a coroutine and then Yield to the normal loop while any individual card needed to animate or play an effect.  I'm going to be honest, it worked.  I could've left it at that, but as a plan it's way below my standards.  It would've been bad code masquerading as efficiency.    

The new plan:

The new plan is not any more complex, but allows for more flexibility and doesn't rely on a janky Unity solution.  I'll simply ride a basic bool back and forth to the main (AI) loop (as I already have a state machine which describes who's turn it is).  As a given card is already responsible for itself and it's internal state, it's trivial to have it tell the main game state that it's done with it's actions and animations.  I'm already doing this mostly, but it can now be extended to animations / effects telling  their owning card when they are done, and it passing the message up the chain.  Not cosmic in anyway, but superior.  I'll blame the holidays on the original plan being so ... foolish haha.

As always, I'd love to hear your thoughts, questions, or ideas.  Let the three days of updates begin!

Eli