next »

[ShrackAttack]

This is looking really freaking awesome so far. Sent you a PM

[Zaibach333]

Haven't updated on here in a while, but we've been busy:

Humans have had their models overhauled.  

There is a ramp in place to better iterate the balancing process in battles, in turn we've had to make more generated leveling systems to accommodate the opposition when needed,  

AI has had some revisions and even a Neural Network machine learning approach (though we found the learning results to hit or miss and we don't have the patience to deal with the slight chance of poor AI decisions, so we're sticking to the more traditional system of decisions, the wait time is about the same to the player),

More powers for classes,

Status effects are more easily visible to the player when looking at units in battle,

countless other fixes and tweaks.

*I feel the character models are really solidifying the look we're going for

[Zaibach333]

Many fixes, additions and modifications, been focusing on content mainly though.

In effort to get more aspects of combat into testing I've been adding logic for melee powers to use on creatures, here's some bite powers applied to wildlife and zombies.  (you may notice the environments haven't been shown before)





Sorry for the long silence, we're still at it :D

[Zaibach333]

For an update, one tough design to tackle is how to teach the player how our initiative track works. I'm hoping adding the Time Units to the initiative viewer will help...

Allow me to explain our use of timing and activation order:

Generally all units in the battle start at about the same time, but ties won by the agility stat, like at the beginning of the battle.

All actions have a set amount of tu or time units it takes up, movement is 1 - 2 tu per square, attacks depend on the weapon, powers depend on the powers.

Delayed powers take even longer but trigger before that unit next activates

and Stats Effects have a duration remaining measured in tu (and can be found in a unit's status tab)

So we show these numbers, but the initiative chart was just showing the order in which units will activate. Now we show how many Time Units from the current unit each have remaining till their next activation.

The only exception to all this is that waiting or defending will take longer than 0 tu, instead the player is set to be after the very next unit in the initiative order, because they're waiting... This system seems alright for me coding it, but I know how all the data fits, would anyone say it's too confusing? I will admit it's all arbitrary values... but they're all visible now.

Thanks

[Zireael]

I like visible turn orders, a lot! That was one of the few things that the infamous 2000s Pool of Radiance remake did well.

[Zaibach333]

Thanks for the insight Zireael, the initiative track is a great tool in general, in this game it was only visible on the player's turn when selecting tiles, since though, we have made it available even while in the menus.

For some Updates,

More accurate height and between separate polygon movement for pathfinding. (this can be most scene on uneven terrain where awkward jumps took place, now seen as just walking, and where dropping down in height is no extra cost, but jumping up in height takes up more movement)

New Cutscene/battle actions: (many of these were added to support new drawbridge or wave based battle scenarios)
-ModifiableLevelObject (trigger visibility or rotate objects from the level)
-SetFaceImpassibility (alters the availability of tiles on or off for future pathfinding in the scene)
-Time Unit based Battle triggers (determine rotation of objects or other manipulation and trigger entire cutscene modules by duration of battle time units)

Rebaking of jump neighbor files for pathfinding on levels has been optimized for quicker iterations while in Unity

The Node system I boasted stopped working at some point during Unity upgrades, so I've resorted to a more component window approach with the same data.

Dialog defined through half of the second chapter and we're 20 cutscenes/battles larger than our convention build was.

Environment assets completed for forest, pine forest, snowy, mountain, sea, aboard ship, caves, tropical.  with a close following for an arid, volcanic, and tribal environments.

Added two music tracks.

Added many creature types.

Added new skills.

Added many new powers.


Here's a clip of previously clunky movement in a familiar level, now fluid:

[Zaibach333]

In an effort to reward players based on their actions, we wound up using a familiar leveling mid-combat used in our inspirations, hopefully our initial fears of doing this doesn't mean battles take a chunk longer with all the extra notifications.  But immediate gratification to actions is a more enjoyable experience to the testers so far.

[Zaibach333]

We've been underway on visuals for Chapter 1, (not to confuse but there's a big prologue, 2 main chapters and a short 3rd closing chapter total)

These are in an important location which makes more sense in the story, so I won't get into it.




We modified the Save screens:



And we added a training option to random battle locations, where you can have a battle where nobody dies, assigning either side  to Player, AI, and even a Player 2 controller.

[MegaTiny]

The new chapter 1 locations look BRILLIANT I have to say. The lift was a very nice surprise. Is there some battle mechanic involving the levers/edge of the lift?

I like the xp thing too, though it feels a little slow. You could pull an xcom and only have it notify you when the character levels up from the gainz.

[Zaibach333]

Thanks!  The levers move but are more for the cutscenes. But we are doing something with the bridge at the beginning of that video, waiting out time units with waves of enemies advancing, hold out till the bridge is down, that sort of thing.

Also only showing xp/sp on level up would be a fine option, maybe we'll make a setting for it.

[Zaibach333]

As we layout the levels, I refined some AI and incorporated our weapons models,  as well as added some permanently imbued weapons you can't find at shops.



Also added skills for meditation, recovering PP instead of taking an action, and concentrate for reducing (or eliminating) delay time on powers (depending on the improved skill or the regular skills applied to the unit)

Upon adding these to the base wizard class, I altered the starting PP to half, which adds another reason to level up in the wizard class for non spell casting classes.

[Zaibach333]

Bomb items with splash damage have been added.

These are a little more like the stone for throwing, so everyone can throw them with the item skill, however those with the Throw Item passive skill will throw farther.

They're expensive to purchase, to push the player to simply level up wizard classes, but it can help in a bind.

Also while it's not our first time showing this scene, it's been improved since last time. I included it's intro before showing a  "Greater Poison" bomb in use.

Bombs have a 5 tile and a 13 tile version in their specific item tiers

[Zaibach333]

We've begun working on Chapter 2 (out of 1 prologue, 2 chapters, and a short final chapter)



We'll have a good amount of content by the time we kick up release planning.

here's the world map around end of chapter 1

[Zaibach333]

Much more content in the works, touched up on some previous scenes from adding a color palette override property.

primary use right now: Night

[Zaibach333]

Much has been added and improved, especially AI speeds.

Something I will mention is we've added a semi coop option to the game, basically done up like the old Final Fantasy's where teammates can be controlled in combat, a feature probably not many will use, but some will appreciate it I'm sure. It is an option which is off by default.

[Zaibach333]

So I've put together a developer showing of some of the techniques we're using with Unity editor tools for Tactics V in this youtube video.
It's geared towards my subscribers who watch my Unity grid combat tutorials, but since starting this project I have neglected to make any new tutorials, and this hopefully explains what I've been up to.

[Zaibach333]

Much progress has been made, but I won’t go into all of it.

Mainly I want to talk about the performance boosts over the month.

Skinned Mesh baking is a daunting task for any who’ve tried it.

In our original plan we had one color so one material per object in the scene, our Skinned Meshes were no different, so we planned a method of combining their skeletons.

We had this process in place with a small editor script for a little over a year.

Now, baking can take a while so we found, so we set out to bake only NPCs/enemies who can’t change their gear.

Our shader system restricts a material to 10 of our color IDs to draw from the palette, since we were doing one color per mesh for most of the skinned models I grouped them by color and group the colors into collections of 10 colors to disperse, differentiating them by hard-coding a uv coordinate per vertex to a generated 10 color texture, separating team colored objects, and things like capes which have cloth on them etc.

What resulted didn’t start out beneficial…

Apparently our script for the past year wasn’t resetting the bind poses of our meshes, though they shared the same skeleton.

After a long bit of research and trial and error we do this:

For each vertex of each skinned mesh, transpose the coordinate to world space from the originating bindpose, according the originating bone weights.

Then immediately inverse transpose with the resulting bindpose, using the originating bone weights. This is the new position of each vertex.

Also we added some bones to accommodate the bone reductions we had imported from Maya, which made the renderer confused.

This wasn’t all though, we could then apply one of many versions of skinned mesh combining which we tried before resulting in re-positioning every vertex.  Every version of combining skinned meshes assumed each mesh had more bones to add, so combining 16 meshes, with our 35 bone rig would result in 560 bones, and that tanks performance.

We had to do a post calculation to remap all of the boneweights to point towards 35 indices of the bones, which could be hundreds of thousands of iterations to the now larger mesh.

Once the new skinned mesh renderer is complete we save the texture asset, the material asset, assign the renderer to a gameObject, store that as a prefab, store the prefab in a scriptableObject, and mark the scriptableObject with the assetbundle of the level the character is for.

The process for how many rosters of units we have for NPCs (enemies) takes 6 – 8 hours, even after some refactoring.

If you take a look though, you can’t even tell we’re going from 209 visible Skinned meshes to 36, and this helps tremendously on lower end hardware.

Static level meshes were easier, baking those was more of a matter of how to group them for their dynamic abilities, can this get transparent when blocking a character, or is this parented to something rotating, etc.

anyway, truly a worthwhile chunk of work.

[Zaibach333]

Version 1 of the content is in:

[MegaTiny]

Yes! Really happy for you that you've reached 1.0. Your game helped to inspire me to get off my arse and work harder on mine, so it's great to see it carrying on so strong.

[Zaibach333]

Thanks! I'm glad it's had that effect.  Many of my posts don't get responses, so it's really nice to hear.  Compatibility and polish remain, but it's a really good feeling to have a new game plus button and know you can actually complete the game now. Thanks for sharing