ok just finished rope climbing.    





Still need to stow the weapon and stop the selector from casting shadows, but it's a good start. 

Apparently, if you can figure-out how to make a character climb a wall you can animate almost anything.   
 
After two weeks of work, all I can say is that it was hard as ***ing hell just to get a basic climbing animation with ledge pull-up integrated into the game.  I now truly understand why some game companies have entire teams of people working on animations.   Integrating animation with code is very tedious and time consuming.



The movement system I wrote uses a combination of translation, root motion, and physics based movement.    Layered on top of my custom path-finding system is a way-point queue that holds pre-calculated movement directives.   This system was the only way to keep the code clean and insure that character does what it's supposed to. 
 
My next step is to add rope climbing, rope swinging,  swimming, and opening doors.     I truly want this game  framework to have a wide range of actions. 
 
Looks like I'll have to construct an obstacle course.   

Lately, I've been implementing one action after the next with little change to the game framework.  The code structure/architecture is finally becoming more suitable and stable, but such is the nature of agile development.    

The latest visible change is the inclusion of physics.   Not only do I want 6DoF, I also want the physics engine to be used as much as possible.    The latest incarnation of this is a crude example I created for the Kick action.        

(note, the targeting selector is bugged and the character appears to be hitting the top surface for 2 extra points of damage.)

Combining physics with a turn based framework isn't without pitfalls.  For example, what happens when a character lands on top of another?   Sure, falling damage based on velocity/mass will be applied to both, but could such an event create a mountain of prone, unconscious, and dead figures?    How the heck will they all climb off each other on their respective turns?   And then, what happens when there is no room (empty squares)  available to exit?

There are solutions to these issues, and some may cause frustrations to the player.    I'm sure I'll still be musing about these details over the next year.   I just hope the pay off is worth it  

For example, imagine a 1 square wide pit with several guarding characters surrounding the top ledge.   As a creature falls from above, all the guarding character get to attack once the falling creature is within reach.  The creature might be dead / cut to pieces before it even hits the bottom.  

This reminds me, I need to implement a gore and dismemberment system.   IMO, no hero should be without limb loss.  

That archery looks awesome!

Thanks.   

I've spent a lot of time working on the camera system recently and I'm kind of burnt out from it all. I think I'm going to move on to something else before my head explodes. 

Integrating archery was a very difficult task.  I've been working on it off and on for months. I'm just happy its mostly behind me now. There were a ton of little unexpected things that needed to happen at specific times; animations had to fire , the arrow had to be instantiated and translated correctly, inventory updated,  physics applied, colliders disabled/enabled/ignored, etc.     
 
The good thing is that I also managed to create a special camera rig for the archery cinematic.  Everything still needs a ton of tweaking.  In fact, I'm sure I'll still be working on it until the end of the year.

Holy Hand Grenade 

The ragdoll/physics will definitely open up alternate battle strategies, if you are able to push the enemy around the map with certain abilities.

Yes, that is the plan. Pushing and Pulling are action types on my list.  I'm even working on picking up objects and throwing them, and that includes throwing creatures.

I never thought I'd be studying film-making, but I guess that's just the nature of video games now.
 
The first stab at cinematics is now complete.    My custom 180 degree Line of Action controller isn't perfect but it's at least functional.   This controller has a number of virtual cameras (Cameramen)  that are setup at specific angles to follow melee action between two combatants.   The camera randomly pans between cameras every second and limits itself to the 180-degree rule.    The focus point calculated by averaging the two character positions. 



(the active camera is switched at random every second.  The actual game will use a more natural algorithm)
 

During an action sequence the Line of Action controller will take over.  I can set the camera to cut or pan between each virtual camera.     The great thing about this setup is that I can have this occur at random and/or allow the player to switch between cameras while they wait for the action to complete.    For that purpose, I'll need to add a few camera buttons to the UI, but that won't be difficult.
 
I'll probably need a few more camera rigs to follow movement and projectiles, but most of the ground work is complete.    At the moment, I'm considering mimicking the famous robin hood shot once bow attacks are completed.

Over the past few weeks I worked on a new  Animation Controller and refractored the Unit Action system.    It was a ton of work, but the code was getting out of hand and in order to move forward I realized I needed to reorganize the class hierarchy.   Every time I do this it seems like I'm having to take a step back to take two steps forward.    I'm starting to think that this is just the nature of game development.   There are times when you feel like nothing is getting done because you have nothing to show except nice code.
 
In addition to adding rats (which no RPG should be without),  I managed to implement object/grenade throwing,   It ended up being a lot more challenging than I had anticipated.  In this case, the requirement to extrapolate backwards from a target location and create a projectile arc demanded an entire class full of projectile math.   Of course, it wasn't the math that was the challenge, it was linking animation events, inventory, actions, collisions, UI, etc..  Hence the need for the refractoring mentioned above.


(not sure why the rats are floating,  they are 50 KG each) 
 
I've also decided that the turn based game will make use of physics and ragdolls.   I'll just have to find a way to seamlessly re position/centre units to the nearest square once rigid-body movement is complete. 
 
As for other features completed, you can now swap out equipment during combat.   Available unit actions are updated on the fly.    I might make changing weapons during combat cost action points.  Opening your backpack will cost  even more action points, this will encourage the player to be prepared.   Of course, armor won't be equip-able during combat and quick items (things located on your belt or across your back) will be less costly.   


(note the character sheet is still a mess, and I'm still pondering its layout and functionality.  Unit stats are still under development )

At this point, I'm fairly certain the game will be a mix of sci-fi and medieval fantasy. 
 
Placing the campaign world on an artificial Dyson Sphere is the first step towards this goal.   To be more specific the game will take place on a number of random discs that orbit the star, creating a Dyson Swarm. 
 
The inhabitants of each disc will live in a medieval fantasy world and be oblivious to the ancient technology that surrounds them.
 
Here is the prototype of this concept.   As you can see, it will greatly change the nature of the world map (hexmap) camera.   I'll probably make it a full featured orbit camera.

[Bonuses vs Percentages?]

Bonuses vs Percentages?

 
At this point, I've made a decision to not include percentage chances.  Players will only be aware of their bonuses / penalties and not a calculated chance.   Complaints and frustrations steeped in ignorance of the statistical realization problem (as per some XCOM fans) won't be an issue.   And really, why should the player / characters have any idea what their chances to hit are?   They might know how good they are, but that's about it.  
 

 
Kicking
Kicking was also implemented, but I think I might add in a push back effect.   Kicking your opponent off the cliff is what this game is all about.  

Just finished adding Ragdolls to the characters.   It was a lot easier than I expected it to be, but I guess after 8 months of Unity development, learning new features becomes rather intuitive now.    With that out of the way, Jumping off a ledge is now an option.  




Currently jumping is an automatic success, but I might change that.   One wild thought I had was that the player would be asked to roll a skill check during the jump.   A die would appear, the player could roll it across the screen, and the game would add in the applicable modifiers (agility, strength, jumping skill, etc) .  That way failure is a combination of player initiated luck and game mechanics.   Without such an option, failure might seem far too punishing.   I've noticed that some players have a tendency to blame the game, but if they interact with the mechanics a little more (by rolling a die) they may not feel that way.  

I think is looking very cool already - your "programmer art" is not bad at all! I think you are definitely on the right approach - nailing down logic, mechanics first, and then assets second. Every time I see a devlog purposefully start that way, it usually ends well.

Seems it's usually the programmers/coders who most often approach their design this way, which makes sense I guess. Anyway - keep at it, because I think you are building something very cool here!  

Thanks!  To be fair, with the exception of the procedural hex map and some textures, most of the assets are free and the engine is doing most of the work

I suppose one drawback to starting out the way I did is the time it takes to get a visual demo up and running.  In addition, polished assets certainly do inspire progress.

One advantage is that all my code is decoupled from unity as much as possible and stuffed into a class library.  In fact, a few weeks ago I entertained porting my game to the CryEngine (since it supports C# and is totally free). The port went well, but I just didn't have the time or the patience to endure the process. Plus, I realized I still have a ton of animation work to sort out and I'd rather do that with an engine I know than one I don't.  

With that said, for the last eight months I've been coding subsystems and not working the game itself.  To a large extent I'm still doing that, but at least I have something show. With the framework mostly fleshed out, the task of adding new features is rewarding and fun.  In fact, in less than an hour I just added kicking and punching.  I've now moved on to adding falling
and ragdolls  I can't wait for Adam to go splat!

all done. I just need to do the same for flying units when they are targeted and selected.  I might also segment the pillar into cubes, that way you can tell how high you are.

Thanks Zireael.

Now that I've thought about this problem a little more, it's not just the movement selector that needs a height/position indicator, the selected unit and the targeted unit require it as well.

With that said, I'll certainly make these optional settings for those who don't like them.

That's a great idea.  Highlighting the tile below is easy.  I could also make a translucent pillar that displays height information.   I'll need to pick something that looks good when the movement selector is above another creature. 
 Thanks.

Here is a demo of the flying feature.   Using the mouse wheel allows you to raise and lower the movement selector.   



Don't mind the animations or the UI, as I haven't even focused on that yet.   

Yes, I haven't shown that yet.  The animations for climbing are still rather ugly, but flying and jumping might be good enough to demo. Perhaps I'll make a gif of that next

[Against the Buggy Mutants - not even Guarding will save you]

Against the Buggy Mutants - not even Guarding will save you

The new Guard feature is near complete. 
Poor Adam, not even his new guard attack could save him.  And the Mutants first attack bugged out.   LOL



 
Guarding (Gold Box Style++)
 
The game will now allow you to spend action points to guard with one or more weapons attacks.   The number of readied attacks is only limited by your action point total.  When an enemy enters your weapon reach, you attack first (gold box game style)  It's setup right now so that all your guarding attacks fire off at the triggering enemy.    I might change that by giving the player an option or only allow one attack per enemy.
 
How does it work?
 
Coding this was really f-ing complicated too, especially when several units are guarding the same square.   Without the internal Event Messaging System I created, the task would be near impossible.   I had to make a TileGuarder class that listened for a number of different events.    The basic sequence of events is as follows.

1. The TileGuarder listens for unit location changed events 
2. If a guard is triggered the moving unit is told to end its movement and pause.
3. The TileGuarder issues a guard attack request to each unit guarding the location
4. The guarding unit issues an attack normally and the attack is handled like any other.
5. The guarding unit issues an guard attack completed message
6. When the TileGuarder receives a GuardAttackCompleted message the attacker is told to stop guarding
7. When all guarding units have completed their guard attacks the target is told to unpause.
 
And this doesn't deal with death correctly.    An overwatch ability (guarding with ranged weapons) is next on my hit list.  Hopefully both systems will play nicely together. 


Don't mind the gif artifacts - I'm not sure why GifCam does that)

This week I worked on the SQLite database.  The game now loads and saves itself using the database.  In addition, I've imported well over 100 different weapon types.  

At some point I might split the database up. I'll create one DB for instances/saved games, and the other for blueprints and modules. That way users can backup their saved games by copying the user.db

I've decided to take a break from the hex map code and advance progress on the combat system. 
Poor Adam, I'll bet he didn't know what he signed up for.