[WIP] Fantasy Conquest Tactics -Turn-based Tactical Strategy

Community Showcases
1

Hello everyone,

I’ve been working on this game for a few months now which already has an actual website blog, and I thought it would be good to also show it off here on the Unity forums as well so that people could tell me if I’m implementing things in atrocious ways. Any comments about design, programming, gameplay, etc are all very welcome and appreciated!



www.fantasyconquesttactics.com

Premise
Fantasy Conquest Tactics is a colorful, quirky tactical strategy game of kingdom conquest and domination, which takes the fast paced, accessible gameplay of Advance Wars, and mashes it up with Final Fantasy Tactics style classes and mechanics.

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.

[

Play on itch.io!](Fantasy Conquest Tactics Demo by Explosive)

1 Like
2

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.

3

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.

4

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.

5

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.

6

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.

7

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.

8

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 implementedUnyielding 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.

9

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.

10

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.

11

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.

1 Like
12

You’ve been making mad progress Kristopher. Impressive pace.
Nice to see a fellow animator doing well.

Are you planning to incorporate actual character models at a future time - or are you going to keep the stylized 3D Max bipeds as characters?

13

Thanks man! I’ll be doing actual character models. Those are just stand ins.

The project has since done a pivot from what it was planning on becoming into something more achievable. I’ll do another blog post soon about it.

14

This game looks quite impressive! I always have liked turned based games like this, keep up the good work! :slight_smile:

15

It looks really nice.

16

I’ve done a huge pivot on this project to be able to actually complete it some day. Going for more of an Advance Wars meets Final Fantasy Tactics now.

If anyone’s interested, I’m looking for someone to take over the main programming on this.

17

A bunch of new features and stuff added:

Mountain terrain type has been added. I’m not totally satisfied with the model/texure, so these will probably get retouched at some point, but they are good enough for now.

The villages are now textured and animation, along with some simple fx. I’m guessing that for tablets, all this will have to be optimized away because currently they won’t batch when there are multiple villages on screen. Also, the building health overlay is in, so when buildings take damage from catapults and other magic attacks, and possibly from being able to attack them with regular troops, it will update make them easier to capture. You can almost think of a village as another unit that’s unable to move, with other units able to stand on top of it.

Unit hitpoint overlays are also now in. They are slightly offset to the right, and the buildings slightly offset to the left, so that when a Unit is on top of a building they won’t overlap. Zooming out makes them scale proportionally do the distance so that they are never too big or too small.

I have started roughing out the HUD elements, which will change color based on the current team that’s active so hot swap games are more clear. Also, you can see the new border edge along the side of the map.

Its now possible to click on Enemy Units to show their attack range, and also show exactly which friendly Units are in range.

Friendly units now also highlight Enemy Units in range. 3 small annoying problems that I fixed were that after you selected a unit, you couldn’t select another unit just by clicking on them, you also couldn’t undo a move after you’d gotten to the set rotation, and also the movement arrow always showed up under your unit, which makes no sense.

Here’s another overlay star effect that will be used for boosed units, or some other effect.

18

As always animation details are top quality.
Really adds ‘fun’ to the experience. Cool update!

19

Perhaps adding some texture detail noise or some rim lightening or gradient shader would enhance the simple polygon graphics.

20

Thanks! If nothing else, this game will be well animated. :stuck_out_tongue:

1 Like