Pillars of Perversion devblog 010

Discussion in 'General Discussion' started by Amra, Dec 19, 2016.

By Amra on Dec 19, 2016 at 10:17 PM
  1. Amra

    Amra Code-machine
    Staff Member

    Nov 7, 2015
    Likes Received:

    devblog 010: trigger warning: techno-babble ahead

    According to my SVN log, this past week I've worked on:
    • rig setup for left + right weapons, including sheathing
    • script for batch retarget/bake/export of animations in Maya
    • stored Unity animation settings + clips in JSON settings files to allow for easy rig changes & reimports
    • Unity project cleanup (removed old unused assets, cleared caches and reimported everything)
    • fixed glitch in idle animation loop
    • implemented combat animations
    • added animation layers for player character (base, full body, upper body) allowing for full body animations that then blend into an on-the-move upper body variant
    • modified Simulation (game logic) module to use fixed timestep (currently locked at 30hz)
    • added custom weapon collision routines
    • added shield bash + sword slash abilities for player
    • added "None" Unit Ability target type for in-place abilities that use manual aiming/weapon collision rather than traditional targeting
    • fixed bug with missed input due to catchup timestepping in Simulation
    • improved 3rd person camera
    • improved landing logic (no more floating up slopes)
    • fixed most remaining C# warnings
    • added ability bar w/ configurable hotkeys
    • added player/target unit status HUD
    • fleshed out unit spawners; they are now serialised with GameData (in other words monsters are saved/reloaded properly now)
    • monsters now die after lingering for a short time. this also persists correctly between saves/loads
    • assorted code cleanup
    .... phew. Now that that's finished, here's a little bit about our game's ability system:

    The ability system for Pillars is heavily influenced by the system Valve developed for DOTA 2 (which I'm guessing was in turn heavily influenced by Warcraft 3 ... and so on, and so forth ;)). I implemented most of it back in August but as you may have seen above, I've just now gone back in to add a few new features such as weapon/attack collisions. So I thought now would be a good time to write a little about it all.

    So, a unit ability is exactly what it sounds like. Examples of abilities might include the Succubus' seduce attack, the player's weapon swings, a passive speed boost, starting a sex scene or attempting to capture a downed monster. When used, an ability begins executing and progresses through a series of states until it's completed or cancelled. Abilities are defined by the actions they perform before/during/after each of these states. The states that I've currently implemented look like this:

    • this state usually plays an animation and then passes straight through to the next (Firing). For aimed abilities like "Charge", this is where the unit performs any turning/movement logic as well
    • for most abilities, this state would encompass the "wind up" stage of its animation
    • this is usually the point where the ability's animation hits the "fire!" frame, damage effects/unit modifiers are triggered, flashy spell effects/particles and sounds might go off and the unit would then start playing its recovery animation
    • for most abilities, this would be the "recovery" stage of its animation; usually nothing will happen here. "Cancel-able" abilities might have some logic or set a flag allowing that here

    So as a super simple example, the player character's basic level 1 slash attack looks something like this:

    • Action: Play "slash" animation
    • Wait until first active frame
    • Action: Enable weapon collider
    • Wait until first recovery frame
    • During cast
      • if weapon collided
      • if weapon collision target is valid
        • Action: damage collision target
        • Action: collision target plays hit reaction animation
        • Action: spawn damage number in HUD
    • Action: Disable weapon collider
    • Wait until recovery finished
    • Begin ability cooldown

    The duration of all of these states is customisable per ability, likewise with the actions that take place. As the library of available actions is fleshed out (for example, enable/disable stat modifier, knock down target, play sound, start particle effect, etc.), we'll end up with a system that should allow most abilities that can be dreamt up to be defined in data and or simple scripts, rather than being hardcoded.

    That ended up being quite long; I'd planned on writing a bit about our custom weapon collision detection but I might save that for a future devblog. Let me know in the comments if you're interested! And don't forget to Like and Subscribe and plz check out my Patreon!

    #1 Amra, Dec 19, 2016
    Last edited: Dec 19, 2016
    Anika likes this.


Discussion in 'General Discussion' started by Amra, Dec 19, 2016.