next »

[Kevin G]

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!

[Kevin G]

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.  

[Kevin G]

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.  

[Kevin G]

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.

[Kevin G]

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 )

[Kevin G]

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.

[Pixel Noise]

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.

[Kevin G]

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.

[Kevin G]

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.

[Zireael]

That archery looks awesome!

[Kevin G]

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. 

[Pixel Noise]

The camera system is intense! Nice work, I was really surprised at all the angles/close-ups, etc. It definitely makes combat feel more visceral

[Kevin G]

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.  

[Kevin G]

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.   

[Nazgum]

Loved seeing the progress on this from the first post and gifs til now; improving a lot over the past few months =)

[Kevin G]

ok just finished rope climbing.    





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

[Kevin G]

With next year fast approaching I realized I had to get to work on finalizing my content pipeline and clean up the UI.  To this end, I decided to take a model from start to finish and even incorporate PBR materials.  
 
Texturing with PBR materials is quite rewarding and fun. I actually tried to apply some of the techniques I learned  painting pewter miniatures when I was a kid, and I think it worked out quite well. Here is my first ever PBR paint job.  Not too bad, but I plan to improve my skills over the next year.  




Although the game framework is still in development, I've decided to start transitioning from coding to content creation early.    I need to know what I can and can't do on my own.   Hopefully, by mid next year I'll have a good understanding of the tools I need and what my limitations are.  
 
I'm also working on a major overhaul of the UI, but it's a slow and painstaking process integrating professional UI graphics.  Actually, in my mind it's just like web development.  
 
As for the game itself, I've decided that all character types will be robots or cyborgs of some kind.   The  reason is that I realized that I could provide more character options and reduce the need for a large amount wearable equipment, as one might expect from a traditional RPG.    Creating armor and clothing stiched to a character model is very time consuming, but with robots such equipment isn't all that necessary.  In this case, I'm focusing on the type of game I can do well with the time I have.

[Pixel Noise]

Looking forward to what the next year brings for your development cycle - sounds like you are thinking ahead and making some smart decisions 

[Kevin G]

Did a bit more work on the UI and multi character features.     I next step is to push the game through a full combat scenario.   I can’t wait to start playing this game.   Starting next year it must be playable or i have accomplished nothing.

[Kevin G]

At this point I have 12 unique character models added to the game.  My latest creation is this little droid creature.    I think I'm going to scrape the internet in search of used up and neglected robots models.   I've found a few so far that I'm quite happy with.    In some cases, I clean them up / modify their topology and give them a new coat of paint.    Some 3d objects need more work than others, but I've got it down to about an hour or so of work per model.    I should be able to add a few dozen different models for character creation.  
 



Typical rpgs provide an excessive number of character creation options for each race.  You can modify your character's hair, face, body size, colors, etc.    One alternative is to offer more racial options and reduce the level customization.    The great thing about robots is that they don't need to be customized.   Sure, there might be a few variations of each phenotype / race, but since they are not biological there isn't a need for complicated model transformations.    I just need to make all the phenotype options numerous and very different from each other, not just visual, but also in terms of the game mechanics.

oh yes, and Star Wars games that don't let you play as a droid really piss me off.