The good stuff: 

Got some basic structure done.  Sadly not much to show, but the backend is coming along.  I had a rather silly epiphany this week wherein I decided to pivot away from some complicated JSON backend for the card.  In the interest of time and rapid iteration, I am going to situate the card data in Scriptable Objects.  This will likely be a massive time saver in the long run, and I can always just port my data into binaries if I'm REALLY that worried someone will data-mine for a wiki or something (I should be so lucky).

Cards are in, and the general structure of turns and energy management is in.  I plan on using this weekend to catch up with UI work and general code clean up, because boy is this thing in a state.

Problems this week? 

Why yes, and chief among them was time!  I suspect, however, that this isn't a problem unique to me.  Specific to sap were all sorts of micro bugs that cropped up due to rushing through for time's sake.  Most notable (and still somewhat ongoing) was slowly working through the mouse controls.  I've used Unity's "new" input system for a large number of projects at this point, so I'm about 72% comfortable with it (haha).  In this case though, I wanted to keep functional responsibilities cleanly separated as if I were a big boy coder, and this ended up slowing me down a little.  The crux of the issue was that Unity appears to offer two solutions for mouse controls within the new input system (or three, depending on how you look at it) and I was unsure how to approach what I want to do.

So what did I end up doing?

As of this moment I am using direct calls to the mouse, which is not how I want to do it.  My solution was really to look into the many ways it could work.  Although I was already mainlining the mouse delta the "correct" way through an Action Map, I was not tracking the mouse position this way.  I'm not totally certain I need to correct this - but initially I was kind of doing both.  I.E. direct calls through code and a delegate based callback.  For now, I solved the issue by stripping out the action map.  Ultimately, I'm using a game state class to hold on to what control scheme is currently in use.  With that methodology I really can stick with the dual idea, as mouse pointer is really the most complicated of all the controls, it's actually somewhat beneficial to not have to feed forward mouse position pointlessly if there is already an inbuild solution for it.  If in some dark future I decide to port this sucker to consoles or something, all I have to do is not include the option to switch and the rest of the code still works just fine.  

One final note:

I do plan on having a video here, just like last week (and likely every week to come), but my YouTube is being weird so I'll update this post with the embed as soon as I can.

Feedback, notes, or just say hi - I'd love anything you might offer!

Eli