Image from unknown source used without permission.

Guardians of the Realm

Welcome to the devblog of Guardians of the Realm, an ambitious Fantasy Xcom game with a randomized map RTS layer featuring fog of war exploration, troop movement, base building, research, and capture and control of resource points.  Scenario based tactical battles will allow incredible combat depth and accessibility, with diverse and customizable character development.


You are the Lord of the Kingdom which has lived in peace and prosperity for generations, but is now under attack by an unknown force from beyond your castle walls, and from within!  Discover and defeat your foe by learning new knowledge, building your arsenal, and defending your lands by recruiting from among your loyal subjects and commanding them in strategic deployments and tactical turn based battles.

Core Design Pillars

  • Feeling of fear, tension, and desperation.
  • Deep but accessible combat.
  • Exploration and sense of constant discovery/reward.
  • Highly customizable and flexible units and playstyles.
  • Streamlined, intuitive visuals, controls, indicators, and interface.
  • Highly replayable.
  • Visually distinctive, production efficient art style set on traditional fantasy setting.

Read More



First off, no this project is not dead. Far from it! The past 2 months have been filled with real life requirements, but there’s still been progress on the game.

While refining the details for implementing weapons and different weapon types, I realized that I would need many more animations than I’ve already got, and that many of the existing animations may not work as needed within the framework of the game. Not all the skeletons of the existing animations were the same proportions either, which I want to make sure they are so hands end up properly placed on weapons, and feet don’t shift around on the ground.

I’m going to limit holding a shield to 1 particular hand to reduce the number of animation variations required, but still allow multiple weapons to be dual wielded, so that each weapon needs animations from both hands. I would also like a few variations of attacks per weapon per hand, so the number of animations is adding up pretty quick.

Casting animations will be treated like a weapon type, with left, right, or both hand attacks, and the hand will need to be empty to cast from, or will need to be cast through a Scepter or Staff. Because of this, the Staff will change to a 1.5 handed Weapon, meaning that it will require 2 hands to Attack, Block, or Counter with, but only need 1 hand to Cast Spells with.

I’m still not sure what to do with Spellbooks and Items though. Adding animation variations for each hand for all the movements would get bloated very quickly, and also the code to manage all that would also need to be done. I may end up going with the approach that Xcom UE takes and just make Items usable from the Inventory without having to first Equip them, and make Spells cast-able from Spellbooks without having to hold the Spellbook in hand.

Read More


Devlog 007 – Inventory and Items

This latest update shows the Inventory and Items work that I’ve done this past few weeks in between some home renovations and moving preparations.  I started with an existing inventory system off of the Unity AssetStore, Inventory Master.  The asset has a bunch of extra features and editor designers that I removed, so I’m really left with the basic inventory, character screen, and drag/drop item functionality.

The Inventory and Items system will work more like the original Xcom UFO Defense with the freedom to carry whatever you want in the item slots, but with some of the simplification of Xcom EU like not having a limited number of slots, and and certain items having limited uses instead of having separate ammo items.  You’ll also be able to pick items up off the ground like the original Xcom UFO Defense, or be able to carry multiple Weapons if you want.  Unlike either system, you can also transfer Items to adjacent Units. (You could technically transfer items in Xcom UFO Defense by throwing Items at another Units feet and having them pick them up.)

I’m using ScriptableObjects for the Items themselves, as this will allow automatic Serialization by Unity for dealing with the data.  In the future if there is demand for modding capabilities, I will switch over to some external file format and deal with manual Serialization.  Each Item is its own ScriptableObject asset, and will be saved in a itemDatabase list.


Read More

GDD: Magic and Enchantments


Magic in GOTR is intended to be developed at about the same pace as Psionics in Xcom UFO Defense, but be a bit less powerful, with no ability to mind control Enemy Units in a chain across the board until you find one with a Blaster Launcher who suddenly goes suicidal.  As much fun as the late game Xcom UFO Defense is, once you hit Psionics and have a few powerful enough Units, the challenge is gone and you have to play pretty poorly to end up losing a mission.  I considered giving each of the elemental magics a Summon Golem spell as a 6th spell, with each type having a slightly different attributes, i.e. Air Golem is very fast, Fire Golem is very damaging, Earth Golem is very tough, etc.  Perhaps those can be included in a future addition.

Having a magic spellbook grants abilities of learned spells within that discipline.  Each Spell must be learned before it can be cast and has a MP cost. There are multiple levels of Spell books, and spells can also be upgraded multiple levels. MP are regenerated each turn.  Some spells will have a delayed reaction and will cast X turns later.  The attack areas will be marked on all difficulties except Hardcore.  Each type of magic has 5 possible spells.

Dark (Enemy only)

  • Summon: Spawns an Enemy.
  • Possess: Take control of Enemy Unit.
  • Terror: Force Moral checks -2.
  • Blight: Poison + Weak AOE.
  • Cloak of Darkness: Causes negative lighting. (tech permitting)

Light (Heroes only)

  • Heal: Heal HP and Wounding on Unit.
  • Dispel Darkness: Cancel Dark Spells.
  • Purify:  Burns an Enemy from the inside out.
  • Righteousness: Boost Bravery in large AOE around caster.
  • Divinity:  Causes rays of light to cast onto Battlefield that do extreme damage to Enemies.


  • Wall of Flame: Creates a wall of flame that does damage.
  • Flare: Illuminates a huge section of the battlefield.
  • Fireball:  Direct attack. Causes Burning.
  • Flamethrower:  AOE attack in front of caster.
  • Flash: Blinds Enemies.


  • Cleansing Rain: Removes status effects.
  • Ice Shards: Direct attack.
  • Fog Cloud: Creates Fog of War in location.
  • Ice Encasement:  Slow and Stuck enemy.
  • Geyser:  Throws enemies into air randomly.


  • Pillars of Earth(3): Can be Attacked and destroyed.
  • Quake:  Causes enemies to fall and lose actions.
  • Boulder: Does damage in a straight line.
  • Spikes:  Direct damage.
  • Entangling Roots: Stuck, entangle.


  • Vortex: Sucks in Enemies.
  • Uplifting Currents: Allows a Unit to fly.
  • Air Armor: Blocks Ranged Attacks.
  • Air Blast: Knockback.
  • Whirlwind: Moves/Damages Enemies.


Enchantments (future)

Weapons and Armor Enchantments are similar to the Relic system used in Massive Chalice, but with more player control.  Since any Weapon can be used by any Unit, you have more freedom with Enchanted Weapons/Armor, and you can also choose how they are Enchanted.  This list is still very WIP, and suggestions are welcome.

Weapons and Armor can have 1 Enchantment placed upon them.  Enchantments can not be removed or transferred.  Enchanted Items can be named.  Many Enchantments cost an Item.

Armor Enchantments

  • Absorb: Some of the Damage dealt is returned to the Unit.
  • Strike Back: When this Armor takes Damage in Melee, some of the Damage is reflected back at the Attacker.
  • Anti-Magic: Gives a bonus defense against Magic Attacks.

Weapon Enchantments

  • Living Weapon: Weapon deals more damage the more Enemies it kills.
  • Anti-Magic: Also deals MP damage.
  • Life Steal: Damage dealt is returned as HP to the Unit.

Read More


Devlog 006 – HUD updates, UnitActions


This week saw the implementation of the Possible Actions method, and the addition of a UnitAction class that contains Action functions and handles the EndAction. There’s now an Action class for each type of action, and all of those that are available to the Unit will get polled into a list and displayed by the UI as Action buttons. The former UnitController functions will get put into each of these classes, to make things more modular. Skill and Move special classes will derive to handle things like Leaping, or special Weapon Attacks.

Another UI update is the Unit health bars being replaced by HP Text instead. There’s a partially implemented visibility indication that will eventually show which enemies each Unit can see.

A few other additions were some ItemAction functions and Attack type functions, and now Ranged Attacks have a minimum distance to prevent using them in Melee essentially.

Read More


Guarding and Shields

Guarding has been added in as a possible Action, and will grant bonuses to defense against front Melee attacks, and slightly less defense bonus to side Melee attacks.  It currently works until the Unit Guarding takes a Wound, unless the Unit has the newly created but not yet implemented Unyielding Ability.  Finishing a Unit’s turn early will also now set them as Guarding by default.

Shields are also now implemented.  I wanted them to give a significant boost to defensive capabilities, but also to keep the choice of using one interesting and balanced, so I’m making them only work when the Unit is Guarding.  I was going to only apply them to Attacks from the front or side of the model holding the shield, but doing so would require a whole TON of extra work, like functions to check which hand an Item was equipped to, and then check from which side the attack was coming from.  Those wouldn’t have been so bad on their own, but supporting animations which could be right or left handed, and all the extra work that would come from that would be way too much for what would be a minuscule tactical effect.

When a Unit with a Shield Guards against an attack, it will get an Armor bonus equal to the Shield value of the Shield.  Ranged Attacks and Magic Attacks will also be able to be Guarded from if the Unit has a Shield, but only if the Attack is not AOE.


Read More

Devlog 005 – Ranged Attack, Attack Deviation, Item Ammo, Pass Turn, Sighting, Partially Visible Enemies, EndTurn Rotation



This week saw quite a few small additions from the Game Design Doc, and some re-design of former developments.  Before getting to the Possible Actions that I mentioned at the end of last week, I realized I needed to get an ammo system working so that Ranged Weapons could tell if they could fire, and would be able to tell the Unit Controller if they were a possible Action to use.  The Ranged Weapon SkillCheck functionality wasn’t completely there, so that is a bit more realized now, and I’ve added attack deviations for missed shots.  The missed shot is much more likely to hit an adjacent tile if the shot is a narrow miss, or deviate wider if the Roll is a huge discrepancy.  Note that this isn’t shown in the video.

When 1 team has fewer Units now, they will be able to Pass Turn to force Activation to the enemy team until there is an equal number of UnActivated Units.  Since the Activation is supposed to be back and forth to react to the Enemy during the Round progresses, this feature prevents the undermanned team from moving the entirety of their side and the Enemy getting to essentially react with the majority of their forces.  I might switch it in the future so that you can only Pass Turn once before being forced to Activate.

I re-wrote the Sighting logic to recognize Enemy Units that are in sight of a Unit’s team, but not visible to the Unit itself.  Right now the Enemy Units are displayed partially transparent when selecting a Unit, but that will probably change later to include some other indication.

The re-design mentioned at the top of the post is taking out the previously existing Unit rotation setting per movement, and letting Units set their rotation at the end of their Turn.  This is the way that Final Fantasy Tactics does it, and it makes more sense because Unit rotation doesn’t matter mid turn, only after it’s turn when the Enemy Attacks.

Another small thing added but not shown in the video either is a new Unit selection hightlight indicator.


Read More


Devlog 004 – Flanking bonus, SkillCheck, EnemyEngagement, Charging, Ranged, InvAction

Hello again, and welcome to the 4th devlog installment. This week I was traveling for a few days, and then took a day to recover from said traveling, so there wasn’t as much progress as I would have liked.  I did manage to get a few minor combat rules implemented, shifted some code around, and have started the foundation for how Actions will be accessed in the Units.

I’ve been tracking my ToDo list by simply highlighting the finished sections in the GDD which makes it easy to see what’s left to do.


A major change in this update is that the SkillCheck.cs has become a static class.  There were too many functions that needed access to it, and trying to pass around all the required variables between classes was getting cumbersome.  Also, since there’s only 1 SkillCheck happening at a time, there was no reason not to make it static.

The flanking code just compares angles of the Unit vs. Target Unit and then assigns the bonus based on the angle, simple:

The EnemyEngagement code used to be 1 giant block, but then when I got to implementing Charging, I realized that I should split it up:

To see if a Unit has Charged another Unit, we use GetEnemyTilesInContact to get a list of Enemies before the Movement, then run it again after, and compare the lists:

The plan for the way Actions will be handled is that the UnitController will build a list of possible actions by having the UnitInventory check which Item or Weapon is equipped, and then determining its attack type and seeing if it has any special attacks available.  There will also be an AbilityManager script on the Unit, which will feed back any Abilities that the Unit has learned, and then filter all that through Status checks to make sure, based on the Unit’s current condition, that it can actually use those Abilities.

Read More

Guardians Of The Realm DevLog 003 – Inventory Items Weapons SkillCheck AnimationEvents

This update shows some of the progress of the new Inventory and Item classes with derived Weapon, Armor, etc classes. The Unit class implements only the Inventory and all the Item management is done through that, which will eventually be connected to a front end InventoryView GUI system to control equipping Items. Armor and Weapon stats are grabbed from the equippped items and passed though to the Unit for use in SkillCheck, which is the class that handles all the combat calculations.

Engagement Bonus is the first modifier that’s been implemented, which checks if neighboring Enemy Units are facing the target, and gets a bonus from the GameConstants static integers which will allow easy rules tweaking later on for balancing. Cover bonus was already existing from TBTK and now is no longer an option. The D20 diceroll is calculated into the Skillcheck, or possibly left out for the options of a completely non random game.

Animations are starting to get hooked up, with timing all done through Animation Events to eliminate the need to do future delay tweaking, hopefully. Once the Skillcheck is fleshed out, it will pass back the appropriate animation to play to the UnitAnimator. All the animations are called by Property references, along with everywhere else possible to allow easy refactoring later if needed.

A bunch of TBTK functionality has been ripped out, like the support of Hex grids, Abilities renamed into Spells, and many Unit functions moved off to a UnitController class, which will drive the Unit wile the Unit class just stores and passes values.

Read More

Character Models and Animations

Added in some temporary character models with animations to replace the basic TBTK Units.  Another reason why I wanted to work on GOTR is that essentially most of the tactical battle character animations are done, aside from some extra casting animations.


I think I may partially revert the movement/action system back to the original TBTK method so that Units can make multiple Move Actions in a single movement, instead of having to make multiple small moves like this gif shows.

Read More

Unit Facing


Unit facing upon move.  If you don’t select a facing direction, the unit will end up facing whatever way it end up after the movement.  Getting this working required digging into the GridManager.cs of TBTK so now I understand the Grid and Tile systems intricacies now.

TODO: Keep final movement file highlighted in green, and force unit rotation to 90 degrees.  Highlight selected rotation facing upon hover.  All that is polish stuff though and will be left till much later.



Read More