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

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

Basic Prototype – TBTK, Unit Selection, Activation, Turn Order, Round Completion

Here’s a video showing basic functioning of GOTR turn structure of selecting and activating units, using actions to move, round completion, and resetting.  The game is being developed in Unity, and I’ve started from the Turn Based Tool Kit which is an existing framework for a turn based tactical strategy game.  Since the TBTK is based around a hybrid system of Xcom UFO Defense TU, along with the concept of a single Attack, I’ve had to hack apart the whole movement system and replace it with the concept of Actions, and flesh out the basic Unit activation function, which was there in the code but not used in any of the system’s configurations, as far as I could tell.  Since the existing AI system was written with the previous movement units concept, I’ve simply bypassed the AI for a while and have it just ending its Activation when its it’s turn.

You can see each unit being selected, using each of its 3 Actions to move before ending its Activation and becoming grayed out.  Next step will be allowing facing determination at the end of each move, implement facing for purposes of combat engagement and bonuses/penalties, and then re-enabling the FogOfWar in TBTK and modifying them to fit GOTR settings.

Read More

GOTR Components-FeaturedImage

Systems Design

Here’s an image of my current rough systems design plan for the implementation of the different systems for GOTR.


GOTR Components

Right now only a subset of these systems are functioning, and I’m sure as I go I’ll end up with something a bit different.  There are a few sub systems that aren’t represented like an eventual UnitAudio, UnitAnimation, UnitAbilities, etc and I’m sure I’ll add a ton more to try to simplify each individual class.  Its been really enlightening to look at other flowcharts for other systems to plan out how each of the components should work and relate to each other.

Read More