next »

[Graphicalgeek]

Premise

Advance Wars meets Final Fantasy Tactics in this colorful, quirky tactical strategy game of kingdom conquest and domination!

Demo now available at: www.fantasyconquesttactics.com

http://collective.square-enix.com/projects/281/fantasy-conquest-tactics

http://steamcommunity.com/sharedfiles/filedetails/?id=774136302

[Graphicalgeek]

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.

[Graphicalgeek]

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.

[Graphicalgeek]

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.

[Graphicalgeek]

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.

[Graphicalgeek]

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.

[Graphicalgeek]

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.

[Graphicalgeek]

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.

[Graphicalgeek]

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.

[Graphicalgeek]

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.

https://www.assetstore.unity3d.com/en/#!/content/26310

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.

[Graphicalgeek]

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.

[Graphicalgeek]

Although this was started as a learning/passion project for myself, I also want to be able to release it some day and hope to make a few bucks doing so to be able to keep continuing to make games in the future. So, after the incredibly long time that it took to do the animations, I decided that I’d like this game to ship sometime before 5-10 years, and since the former game design would probably take that long with a team of 20, it was time to cut the scope of the project. More than cutting the scope, it would need an entire pivot to ever see the light of day.

Since I’ve been playing a bunch of Advance Wars inspired games recently, and since I also really love the original games myself, I thought that the Advance Wars style design could be used to take the formerly separate strategy and tactical layers, and combine them into 1, while also keeping many of the core design principles I set out with.

Enter Guardians of the Realm Revisited:

Note: The Units are temporary placeholders.

One of the major changes is that the base unit(Peon) will only be able to capture Villages, and not Keeps or Castles, but can be built from Villages.  They will also be able to repair Buildings, which none of the other Units are able.  I'll also introduce beast Units later on, which won't be able to capture any Buildings either.  Many abilities will also be based off the strength of Units, so they will be less powerful as Units become damaged, similarly to attacking.  This will also apply to Buildings which only produce a Unit with as much Strength as the Building, and also for healing Units, so keeping Buildings repaired and at full strength will be vitally important.

[ArzNova]

I actually think I prefer the new style of art, to be honest! I think it stands out much easier than the previous, more realistic style. Nice work! 

[Graphicalgeek]

The old art was all placeholder anyways, but I'm glad you like the new style!  :D

[Davi Vasc]

Aah Advance Wars! The memories...

In terms of medieval/fantasy Tactical RPGs I think Fire Emblem is pretty much dominating the niche right now. The good news is that FE is only on 3DS nowadays, so you will definitely be able to get people's attention on other platforms, specially if you have a unique twist like a cool artstyle, mechanics, etc.

Looking forward to seeing more of it!

[Graphicalgeek]

Its only been a few days since the last post, but there’s been a bunch of new features and stuff added that I wanted to do another post early.

 

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.

[Graphicalgeek]

Gradient background added courtesy of a script off of the Unity wiki.  Also added an undo button near the ‘Select Next Unit’ button.

 



It took quite a while to change the movement to be click-select, click move, but it needed to be done because of future touch controls.  Also tile highlights now animate, and characters run to help show they are selected, along with sound support.

 



Minimum range implemented, along with 2nd click to show range for friendly units.  3rd click ends their action.

 


Tiles can now be selected, and update to the HUD.  The tile information about movement and defense still needs to be implemented in the Tile class before that can also be displayed.

[Graphicalgeek]

I'm still looking for a programmer to help with pathfinding/AI and general programming.  Project is Unity, with eventual iOS/Console targeting, so explerience there is a plus.

[Graphicalgeek]

Movement selection now highlights tiles as you mouse over them.  Also changed the arrows a bit, and the end tile highlight style.





Castles are now animated, and all buildings have a selection animation.



A fun accident when setting up the tile highlighting.

[Graphicalgeek]

Very pleased to announce that basic combat is now working.  Terrain modifiers are not calculated, and neither are multiple attacker bonuses, but flanking bonuses are applied.  There's still no hit FX functionality yet either, but that can come much later.  Aside from the flanking and multiple attackers bonuses, the damage formula is very similar to Advance Wars, but with one distinction that a Unit's defense isn't altered by its Hitpoints.  I felt that this would keep injured units from becoming completely tinfoil once they take a few hits, and because I want Units to last a little longer in general compared to Advance Wars, since you'll probably have less of them.

The other big distinction is that there's no randomness in the calculation.  Why?  I'm hoping that the straightforward and simple feedback makes the game more approachable, and that the removal of the uncertainty of killing a unit decreases the deliberation on whether or not to take the action, hopefully improving the overall flow.




I also made a bunch of other minor fixes and tweaks.  One of them is that map rotation now rotates around the selector.