The good stuff: 

Hey everyone, I'm more or less taking it easy this week -> as I hope you all are as well!  I am going through and working on refactoring some basic elements of the game before I dive into wiring up the early menu UI/UX experience.  Just for fun visual flavor, here are some new cards  I drew (though I won't spoil how they work just yet!):

I also took a little time to draft up the graphic for the back of the cards, so they can actually be flipped, and so they can form a deck. I also drew up a little deck to serve as a place to deal cards from and to function as the end turn button.  Card cost has moved off of the cards into its own display.  This is so when I redesign the tooltips they can be slightly more useful and have a little graphical element to them.  I just have to bend text mesh pro to my will.

What's the news, issues?

Any problems this week?  Not really, especially not as compared to last week.  Like I mentioned, I'm taking it a little easy this week although the weekend is fair game for big work, so there's the  possibility I might drop a second devlog following it.  As for what I have been working on, the way the cards themselves stored data felt a little less than extensible for me, so I used this down week to design a more future proof solution.  I had originally conceived of a single class which stored all needed cards for data, but I've realized there's a little more complexity than originally considered.  As such, I've ripped that class into a base class, and basically any card with functionality over "sit there" will fall into an inherited class of some kind.  The big thing for me to work through now is how to organize these classes.  I already have a system of categorizing card types, so I might be able to slightly expand and use that.  This might end up limiting me a little in the future, but it's overall a better idea. 

I streamed some development on Wednesday evening and had some friends drop by.  One articulated an interesting problem where this devlog is concerned: who is the target audience.  It seems that my audience (at least for now) is fellow or aspiring game developers.  Given that I'll probably start formatting my posts so that there is a section for content update, and a section for a deeper dive into the business of designing this game.  One of the things my friend thought might assist in making the general development process more approachable, or even to bridge the gap between potential fans of the game and fellow developers - an overview of the architecture and my thought process behind it.  And so...

Architecture: Part One

I'll start with just a really general overview, as I do plan on posting again soon, and I want to get back to spending time with my family!  While I do love ECS (Entity Component Systems) and data-drive design in general, this is a fairly straightforward project so I opted for a basic OOP design.  This fits nicely with Unity's front end (baring the DOTs debacle) and is simple to implement.  The second big rock is overall control flow.  This is a simple game, and the only real complexity stems from information flow / control and the AI manager.  To this end I'm trying to be careful to keep aligned with SRP (Single-responsibility principle.)  Given Unity's MonoBehavior pretends to be event driven (as I understand it, which might be incorrect, Unity uses SendMessage under the hood for for many functions), and can be notoriously heavy when it comes to tapping into the core loop to pass info - I went with a single through point for references.  Thus the GameManager, which serves as little more than as a bag of references to other classes and home for the current state of the game.  

So the general flow looks something like a really lazy Singleton Mediator.  For example, let's say the AIManager needs to produce a new card, as something been born on to the board.  The AIManager reaches through its reference to the GameManager and into the CardHandler.   In this way cross talk is achieved through a few static references.  It's not cosmic, and it's honestly fairly lazy - but it will work for this project without issue. 

Yeesh, this was a long one!  I realize this is a little sloppy, as overviews go, but hopefully it'll become more clear as I dive into some of the more granular elements of the game's design.  As always please leave any comments, thoughts or ideas!  I'd love to hear what you're thinking!