After a bit of further R&D I decided to scrap all the humanoid artwork and move to a new base:
The old base was too chibi, not flowy/edgy enough and had practical issues.
If the old base was heavily FFT inspired, then the new base is basically a complete HoMM2 copycat.
I don't want to copy XCOM style bases, because with all due respect, XCOM pixelart was far from being perfect.
I think I can do better even with my programmer art skills.
And I really love the HoMM2 graphics, over HoMM3 and HoMM4, despite HoMM4 being my fav game design wise.
In fact I borrowed several ideas from HoMM4, as that game had nice adventure feel, similar to the Rings of Power on Sega Genesis. And I liked the bottom-up approach to character classes, where the heroes gained classes based on their skills. For Spell of Mastery I came up with a 4 primary attribute system: ador, craft, faith and bond (BAFC - bond-ador-faith-craft). These variables (which I call talents) control how passionate the character is (risky vs careful), if the character prefers clever way to solve problems, if the character is faithful into the chosen god and the own action and if the character has good skills on forming bonds (basically D&D charisma with a huge twist). Then there is also chaos, order, life and death system (which I call COLD), which combines with the attribute system. Together they control what the character can ultimately do. And it is not possible to create a universal do-it-all character by setting all attribs to max, because say high ardor character will have numerous development branches closed, especially on the path of order, yet at the same time have development branches open on the path of chaos. And then all characters begin as commoners, your usual human beings, and moving to the path of order or chaos will require special rituals, which are not always possible (that is being controlled by the COLD attributes). The humans are jacks of all trades, and yet even a high-tier human mage can't compete at order magic with the one on that path, especially if such mage has aptitude towards order. For humans BAFC+COLD together produce the "cosmos" determinant, which basically says how cosmopolitan and generalistic the character is and if it can succeed as a human being, and characters with high cosmos can't succeed on the non-human paths.
But that all is mostly for the background, since the characters player will hire, although can develop further, will come with all the skills necessary for the game. So it is not required to understand this system or do through character to play the game. It is more for my own convenience to add depth to the game, so characters wont feel static and will have unique personalities. Give that I have 5 sates per each attribute, and there are 8 attribs BAFC + COLD, and I have 5**8 = 390625 different possible psychological profiles for characters. That is not much, but beside these static talent profiles, characters have dynamic skills, which although determined by the talent profile, can changed through training. The training state of these skills actually determines the character class. To generate the mercenaries for player to hire, the engine actually does the backtracking from the class requirements to skill, to talents. Basically it isolates a subset of all profiles matching that class, and then picks one at random. Similarly to how Prolog does it. Again, that happens behind the scenes and player doesn't really need to understand it. But it is impossible to implement with pen and paper, so I hope I drifted far enough away from D&D by turning the core idea behind it inside out.
I know for people accustomed with D&D such name will sound crazy, but I believe character systems should be more about psychological side, and appears to transition nicely into actual game mechanics code. Moreover, this system runs on top of the existing gene and gene-expression system, which is more about the physical fitness and status ailment (like the character being poisoned, losing limbs or eyes). That COLD system was actually featured in several prior games, among them Lords of Magic and HoMM4, which completely abandoned the previous Might & Magic games elemental approach for this math styled based axiom system, which then expands into the elemental things, as a side effect. Lords of Magic still had water/earth/air/water elements on the same level as the chaos/order/life/death, but the designers there, despite being really smart and innovative, had cloudy understanding of what they are trying to achieve. Recently a new game, Songs of Conquest, stole a lot of ideas from Lords of Magic, including its city development approach and the unit stack size limitations (as a fix to the single-hero issue of the original). Another HoMM clone, Hero’s Hour, took real time aspect of it, plus the army composition display on the world map, instead of just that single boring hero sprite. Hopefully in 25 years or so, somebody will finally make an ideal HoMM style game, with all the design issues fixed.
That all seems so insanely complicated, but my game began as basically a Warcraft II engine implementation (
https://www.youtube.com/watch?v=-k8jkeFfnl0 ), back then in pure Common Lisp (SBCL compiler), which I then ported to my own Symta language. And it was actually a full blown Warcraft II implementation, copying 1-to-1 the AI behavior and I even had all the spells were implemented. Compared to Spell of Mastery, the WC2 project was really simple and took me just two month to implement in Common Lisp. Then I decided to turn into my own thing, and I planned to make a puzzle game akin to DKPuzzle.pud map for WC2 and CoreWars, because WC2 engine is basically a cellular automata, and therefore inherently puzzle friendly. So there was idea on combining all kinds of puzzles into a Rube Goldberg device, with a bit of strategy elements. But then I decided that 2d is too boring, and the game really needs 3rd dimension. WC2 tile engine was unsuitable for that, so I turned it into an isometric engine, very simple at the time (the one I currently have uses dependency graph to implement the painter algorithm). But then I found that solving sokoban puzzle in real time, while enemy attacks you, as a bit annoying. So I added pause. That haven't improved the gameplay too much. So I moved the game completely into turn-based mode. Initially it had a final fantasy style / heroes of might and magic scheduling, where units moved in accordance with the speed, which is basically an extension of the Chess scheduling of player moving 1 piece a time. In fact you can add this scheduling to Chess, and at one point I actually tried giving units actual chess like movement patterns. That worked but was kinda gimmicky and the scheduling proven to be too annoying, since turns were too short and player was interrupted by AI moving its piece. So I moved to the XCOM style whole team turns. And then it was like... fsck it! I'm making an XCOM clone, but with everything different from XCOM.
As a former Warcraft II engine my game had no accommodation for character development, but it had a system of dynamic status ailments for spell effects like haste and bloodlust. That system was also used for unit upgrades and the units inside of buildings. And everything dynamic, including inventory, was built around it. It allowed somewhat complicated stuff, like the WC2 flame shield spell, of flame sprites rotating around character or the blizzard spell projectiles falling down. In fact, I abstracted it into gene and gene expression concepts. Yet the problem I encountered now is that genes are hardcoded into unit type, which was shared across different units. And when you move to unique characters, there is just no type and every character has to carry all necessary genes. So now I'm struggling with getting rid of the static class system. But I still have to maintain it for static objects, like tiles and trees and rocks. Then again, maybe all trees and rocks should be unique too? Modern PCs have resources for that, but I was always into premature optimization, unnecessary limiting myself by making everything static by default, even inside a dynamic language. Anyway, it is still an RTS engine, and at one point I had a bug, of several units moving at once, out of their allocated action points, since the engine can schedule such movement.
Anyway, dunno what to do with the old art. Guess I can sell it for a few bucks. Still a shame I lost so much work due to bad planning.