Guessy Makes Videogames

[Guessmyname]

Hello there; I'm Guessmyname, and I make videogames. Eventually, I'll even release one of them...

Generally, I make a heck-ton of prototypes. I've a fair few that've got good progress on them to the point I'll probably be looking to pitch them to a team, for which I have a number of contacts (people I've worked with before, beating the drum over at TIGsource, here if there's anyone interested...).

I started out as level design / art back in the Source / Half-Life 2 modding days; if you've played Jailbreak: Source, Nightmare House 2 or GraviNULL you've probably seen some of my work (JB's King of the Hill mode was me, I did a lot of props and the zombies for NH2 and a few maps for GraviNULL). I also did a few props for No More Room In Hell, though not that many (tl;dr "University Happened". The objective props like the gas cannisters are mine though).
From there I took Games Art at the University of Bolton... which actually turned out a little redundant at the time because I already knew how to use 3ds Max and took up games coding and development in Game Maker and Unity.
After graduating, so far I've worked with PixelSpill on Katatak and a number of other projects, learned to drop and hate GameMaker (it murders tablets, forced a project to swap engines half-way into development and literally nearly killed our coder from stress. Friends do not let friends use GameMaker, try Construct 2, Godot or something) and have been working and improving in Unity and C# ever since.

Current projects:

Turn-Based Tactics Framework / Build-Your-Own Tank game "Godless Century"
I actually have a bunch of design ideas that involve the words 'turn-based' and 'played out on a grid of some sort', so I've been working on a set of tools and so on for building turn-based games playing out on various grids of sorts (Hex, Iso, Square, Arbitrary, etc; it even lets you mix them without giving a damn thanks to C# interface magic).

The current project I'm working on on the framework I'm on working on is 'Godless Century', a tank-building game inspired by Advance Wars 2, War Thunder, Kerbal Space Program and an unhealthy obsession with WWI tank development. Build your tanks and let them loose against the enemy in a game of positioning, cunning and desperately pretending recreating the Tsar tank for giggles was a good idea.

At this current time of writing the basics are in place: you have units you can order around, there's a level editor, tanks can shoot at each other at be disabled and you can even edit the tanks in the unit editor, but there's only one set of working parts to build things out of. The AI can shoot at you... and not much else at the moment. That's my current point of focus.



My standing goal is to bring GC to a 'playable alpha' state:
- An AI that is capable of winning a match (however theoretically). Currently they only shoot the centre mass and never move, so they never knock-out your tanks.
- Proper match win/lose detection (currently it detects when a team is out of units but not much else)
- A few more parts for tanks so that the unit editor is actually worth anything, plus making the editor actually user friendly.
- More robust hit detection, it's a little wonky ATM

Other 'high priority' but not necessarily 'playable alpha' features todo:
- Fog of War, Line of Sight and crewmembers / visibility.
- Infantry maybe. (Infantry are important to the game design but not necessarily the playable alpha. Depends how easy they are to implement really)
- Some form of lightweight in-game modelling tool for custom tank hull/turret designs
- Fully weaning parts off of the Unity Editor (ie all parts are stored externally and loaded at the start of the game and new ones can be added without a recompile; currently they're unity prefabs for ease of development).

From there, Godless Century would definitely need a proper team to get off the ground, but it should be in a good enough state as a proof of concept to attract attention. I may or may not release playable alphas, it all depends on who I wind up working with.

As I said, there's a few other design ideas I have for TBT games, but since they would all operate on the same framework as Godless Century... I'm mostly just working on Godless Century. As such, the other ideas are only design studies / 'games on paper' and not much worth discussing at this time.

Isometric 2.5D Framework / One Day I Will Make an Adventure Game, Damnit!
...I've tried a lot of times to make an Adventure RPG, okay. Primary inspiration is Dark Souls for basic combat rhythm (ie 'it's all in the animations and positioning') which I find so vastly more interesting than Dragon's Age-esque 'watch two characters stand next to each other and hit each other'. Alas, however, I am but one developer, and one developer cannot hope to recreate Dark Souls all on their own. So through a variety of trial, error and design studies I've been trying to find a design / project arrangement that emphasises efficiency whilst trying to sacrifice design depth as little as possible.

Currently I'm looking at building a 2.5D isometric game/framework that would let me do 2D sprite art for environments whilst using 3D models for characters, rendered to sprites, only performed at runtime (think how Fallout 1 and 2 handled characters and you're on the right track).
2D sprite art for environments is fast and really fun to make, whilst still being very reusable, letting me create levels and prototypes quickly.
3D characters and animations meanwhile eases the animation burden by making animations very, very re-useable (one attack animation can be used by any model with a matching rig, played at any angle and you can do runtime lighting p.much for free) and lets you do funky stuff with modular/customisable characters and procedural animation, things where a 2D animation will fall down (in 2D animation, one attack may well require multiple animations be drawn up for the various directions, along with various other difficulties).

This is all currently in what I'd call the 'technical alpha' stage; I'm building tools and investigating if this is possible. Currently, I've got the 2.5 isometric spritemaps working, next target is the characters.


As for what the game itself will be, that's something I'd prefer to cover later (once the 2.5D approach is confirmed as go).

Other Stuff
Yeah, there's other stuff. I'd prefer to talk about those as they come up, they're mostly just 'prototypes and ideas' I dabble in to see if it's worth pursuing. Stuff like recreating Wind Waker's art style, mucking around building a bullet-hell duelling game in a destructible environment or trying futilely to get a decent Boss Generator system up and running (I've been trying for years ever since PMMM came out).

Mostly, I'm envisioning this thread as a place to post updates / show off WIPs and hopefully get feedback / interest from folk. I'll probably talk game dev a fair bit too on the technical side of things. Currently I'm mostly investigating AI theory for Godless Century, mucking around with the rendering/tech shenanigans for 2.5D Iso, and periodically prodding the half-dead procedural boss horse.

If there's stuff you want to ask about, ask away! For the record: I am always up for Game Jams, unless already participating in Game Jams. Jams are delicious.

 

[Look to the Left]

I would think that working on one project at a time would be a lot more easy although people can and would call me a hypocrite because I work on two quest and playing in multiple RPs.

Anyways I'm very much interested in these games. Also what makes Gamemaker bad and Construct 2 better?

 

[Guessmyname]

I would think that working on one project at a time would be a lot more easy although people can and would call me a hypocrite because I work on two quest and playing in multiple RPs.

Click to shrink...

I tend to have one 'mainline' project (this being Godless Century) and a few 'side' projects to try ideas, prototype or generally 'do stuff that the mainline project doesn't'.

The majority of my time is absolutely spent on GC, but my side projects are essentially there to experiment or cut loose a little. I find it helps evade burnout, personally.

Anyways I'm very much interested in these games. Also what makes Gamemaker bad and Construct 2 better?

Click to shrink...

Performance. Gamemaker runs like a hog on tablets and is nigh impossible to optimise; it's why we had to swap engines mid-development. Construct 2 I threw out there for having the same feature set as Gamemaker (ie 'visual coding'), but I don't actually use it personally since I can code a storm up in Unity instead. We actually switched to Cocos2D in our case. I was an assistant artist rather than coder on that project so I don't know the full technical details.

Either way, the stress it put on our coder to do the switch, recode everything from scratch and still try to hit publisher deadlines actually put him in hospital. We're... not fond of Gamemaker any more. We're not the only team that's had to do this, either; Gunpoint springs to mind as a game that started on Gamemaker and then migrated.

 

[Look to the Left]

Huh, guess I'm sticking with construct anyways. Also my first coding experience is QB45 switching to QB64. Any advice in making games cause I'm one of those guys interested in the work. Any advice will do.

 

[Guessmyname]

Huh, guess I'm sticking with construct anyways. Also my first coding experience is QB45 switching to QB64. Any advice in making games cause I'm one of those guys interested in the work. Any advice will do.

Click to shrink...

More than anything? Efficiency is king. As a starting/solo dev, one of the major obstacles is getting enough content together to make a game. And I mean content in every field, not just artwork; mechanics, levels, sound, etc. All these things take time to produce.

So work on your efficiency. Use tools and workflows that let you re-use assets; tilemaps for example are things of beauty in level design. If you can't go tilemap (ie you're working in 3D), go modular. Model a wallpiece and a doorway and you build nearly any configuration of building you can imagine (this is how the Unreal team builds their levels, for instance; they have a number of articles on it). The shorter you can keep your content pipeline, the better; Unity for example can import Blender files directly, and will automatically detect changes to content, hence avoiding the constant export/import slog typical of most engines and tools.

The faster you can make content, the more content you can make, the more game you have. This isn't to say you should rush or sacrifice quality, but always have an eye towards being as efficient as possible, because as a developer time is your currency. Everything you make, everything you want to make, will be paid for in the time it took to build it. Animations in particular are bastards for this; good animation takes so much time, so plan how many you'll need carefully.

Equally, try and keep things simple; the good ol' KISS principle (Keep It Simple, Stupid). I'm admittedly terrible at this, but again the less you have to implement the sooner you will be ready. It can even help you focus your design; look up 'design by subtraction' and the development of ICO for example. Game Jams are spectacular at this; you have a week/few days to make a game with a given theme; get to it! They're excellent challenges at how efficiently you can build things.

There's a degree of combinatorial complexity; any given 'thing' in your game is going to involve animation, artwork, scripting and sound (and ideally you do want all these things, because they communicate to the player what is happening), be it the player, the environment, pickups, enemies, whatever. By paring down and focusing, you can make a few key things shine instead of spreading yourself too thin and at the end of it having a whole lot of mud to show for it.

On the tool front, I recommend Unity for game engines, Blender for 3D modelling and Krita for 2D artwork (I actually use Photoshop because I was trained for it and have a license but shhhh your wallet can be spared my pain). All three of these things are free, Blender has the advantage of direct Unity import and Krita has recently expanded into animation and normal mapping tools (though I'd recommend something else if you're going for pixel art).

Part of why I like Unity so much is its Component-based design, which essentially lets you be modular with your code as well. A component should largely serve only one purpose, and then every time that purpose comes up you re-use the component. Health would be the classic example; want a damageable enemy/box/boss/door? Have a Health component that spits out messages at 0 health. Then when your attacks detonate, they just scan for Health components, damage them, and the gameobjects react however they need to (playing the death animation, breaking the box, smashing the door open). It's all about re-use, so that you aren't recoding the same functionality 100 times, and whilst side-stepping the inheritance snarl that usually crops up when working with tree-based design. Plus it's C#, which is infinitely easier to use than C++, and for that reason alone Unity > UE4 in my book.

Equally in Unity's favour is the Asset Store, which... well, lets you essentially find pre-made 'features' or tools for your game rather than having to write your own. ShaderForge (UE4-style node-based shader editor), SuperTileMap (Tilemap editor with TILED support) and Behaviour Designer (Node-based behaviour tree builder / visual coding scriptor; very very useful for building AIs) are my particular gotos. Downside is they do cost money. Upside is your not spending a ton of time working on tools instead of gameplay.

Finally I should also make a note about prototyping. Given everything I've harped on about 'efficiency in game dev', making throwaway prototypes might seem counter-intuitive. It actually isn't; it's the 'Fail Faster' principle. Generally, the only way you're going to find out if a given idea or design won't work / isn't fun / can't be implemented is to make it and find out. The beauty of prototyping lines in finding out as fast as possible with the least effort/time/content cost. You don't want to spend forever say, animating and modelling a beautiful character for a game design that is fundamentally not going to work.

Technical implementations are also particularly prone to having to constantly change on the fly as you find bugs, solve problems and all the other mayhem on the road to a finished game. I'd actually only recommend delving seriously in the art side of development once the technical/mechanical side is mostly secure (ie 'at least playable alpha' stage) and you know what kind of requirements and constraints will be placed on the artwork itself. The only real exception to that rule is 'artistic games', where exploration/art is the whole point, in which case yeah; build your design around the art. It depends on what element is more important, really.

 

[Lydia]

- Fog of War, Line of Sight and crewmembers / visibility.

Click to shrink...

Have you much experience with this?
In the game I made it was the hardest part up there with writing our network protocol as it either crashed the hardware, didn't work or made all units standing in the dark.

 

[Guessmyname]

Have you much experience with this?
In the game I made it was the hardest part up there with writing our network protocol as it either crashed the hardware, didn't work or made all units standing in the dark.

Click to shrink...

No experience yet but I'm aware it's a complex topic. It boils down to "how cheap is the 'is this tile in view?' test" and how you store the information, as I understand it. It's much, much more complex in a continuous space operating under continuous time; at least in my case I can go by tiles, and I'm going turn-based, so I don't need to recalc visibility every nth of a second, just after every move.

Even as far back as Total Annihilation though you had LOS that respected 3D terrain, so there must be tricks to it. It's all about the 'in view' test.

In my case, I'm planning to do the following:

1. Have a simple 2D byte array storing the 'is this point in view?' answer for each team (we're using bit flags here; we're essentially storing 8 bools in a single byte. Incidentally this makes our max supported teams 8 unless we want a second map for teams 9-16). We'll call this the Visibility Map.
   
2. For each Unit in a given team...
   1. Have a cached 2D bool array of the local 'potentially visible set'. The PVS is simply a square region centred on the unit's position, the size of its view diameter (ie view radius * 2). It is also stored as a 2D bool array.
      
   2. Check if the map has changed or if the unit's position has changed since the last visibility calc. If neither of these are true, we do not need to recalculate the PVS for this unit.
   3. If we do need to recalc PVS, then we do the following. For each position in the PVS:
      1. Check if it is actually within the unit's vision range. It's a square region, so they won't be at the corners. This is a simple geometric test.
         
      2. Check the relative height of the tile compared to the unit, and that of the nearest neighbour to the unit. We can use this to make tiles higher than the unit invisible, but only if the nearest neighbour tile is also higher (ie units on cliff edges will still appear). It's kind of a hack, I'll admit.
      3. Do some sort of vision test for the given tile. This may mean different things for different tiles, such as hiding units in woods.
   4. Add the unit's PVS to the full-size map array (this will mean some transforming and checks to ensure we don't have problems with, say, units at map boundaries. It's also additive, ie it will only make invisible tiles visible, never the other way around. Unless you're implementing the Red Alert Gap generator or something).
3. ...Figure out some clever way of rendering this thing, heck if I'm sure yet. In full 2D this is relatively simple (you could literally use a texture for the Visibility Map and PVS and just draw that over the screen) but Godless century isn't sssso... I'll jump that hurdle when I get to it <_<. The map rendering is only a prototype at the moment anyway; it doesn't even support textures yet.

This is all entirely theory, however. I haven't had to tackle this problem yet, and I have the easiest use case for performance! For runtime, I'd look at trying to offload the visibility calculations onto a separate thread and possibly some sort of queue system, such that you're limiting the max visibility calcs per frame and prioritising the units on the screen.

EDIT: On further reflection it could also be possible to do visibility on the GPU using 2D lighting techniques. Think something like Light2D only the output is stored in a rendertexture; you query the visibility of a location by testing its corresponding pixel in the rendertexture. I'm not good enough at shader wizardry to say how exactly 2D GPU lighting works though.

 

[Lydia]

• ...Figure out some clever way of rendering this thing, heck if I'm sure yet. In full 2D this is relatively simple (you could literally use a texture for the Visibility Map and PVS and just draw that over the screen) but Godless century isn't sssso... I'll jump that hurdle when I get to it <_<. The map rendering is only a prototype at the moment anyway; it doesn't even support textures yet.

Click to shrink...

This was the hardest part at least for our team.

I think you could get a better performance if you save the units of a team in separate arrays and iterate over this array and not the PVS,
you can't know which tiles would be visible in the new configuration, so your algorithm would need to check the whole map. If you don't have to many units it should be faster as your algorithm would need m*m checks and this algorithm would need u*v checks where m is the size of the map array, u is the size of the unit array for one team and v is the number of tiles in the view field of a given unit.

 

[Look to the Left]

I have a hard time understanding any of this but maybe that's because I still new to programming and stuff.

 

[Guessmyname]

This was the hardest part at least for our team.
And I think you could get a better performance if you save the units of a team in separate arrays and iterate over this array and not the PVS,
you can't know which tiles would be visible in the new configuration, so your algorithm would need to check the whole map. If you don't have to many units it should be faster as your algorithm would need m*m checks and this algorithm would need u*v checks where m is the size of the map array, u is the size of the unit array for one team and v is the number of tiles in the view field of a given unit.

Click to shrink...

Ah... I think you're misunderstanding how it works. The PVS is stored on the unit itself; each unit has one. It's essentially a local description/cache of what the unit can see, not what all the units can see (I have some planned gameplay features that can make use of this difference). The Visual Map is calculated by iterating over all the PVSes and adding them together (offset such that their centers line up with their unit map positions correctly). This way I can update the PVSes on an as-needed basis and regather the visibility map by adding them all together.

Say I have a unit with a view radius of 5. Its PVS is a 11x11 sized 2D array. PVSes need only to updated infrequently.
The Visibility Map quite literally spans the entire map, so for a 100x100 tile map, it's a 100x100 sized 2D array. Updating the Visibility Map involves iterating over all the PVSes, but does not have to perform any calculations involving the tiles; the visibility is pre-calculated in the PVSes, kind of like how Deferred Rendering gathers all lights them applies them in a single pass.

Because I'm a cheating bastard making a turn-based game on a tile-based grid, I can be cheap as bugger and only update the PVSes as needed, which typically means 'when the selected unit moves, recalc it's PVS'. Even if the map changes and I have to recreate all the PVSes for every unit on it, I can spread the calculations across multiple frames without affecting gameplay much (though obviously I'd prefer not to have to do that).

Per frame, I can fairly expect to only be regenerating a few visible sets at a time.

As I mentioned / edited in earlier, realtime recalculation over a continuous space would be a much different proposition and could potentially be shoved off to the GPU in some way.

 

[Guessmyname]

So! It's been a few days, but I've finally (finally) gotten the isometric sprite thingiewhat to a stage where you can actually dev games with it. Which is to say 'now it has colliders'.



Sprite handling was a bit of a pain here, as it turns out you cannot actually modify Unity's Sprite objects; the only way you can change them is by horsing around with an asset preprocessor aka 'I hope your workflow dies in a fire'. So instead of 'make tilemaps from sprites' it's now 'make tilemaps from tile prototypes that initially made from sprites but don't actually use them'. There are some positives to this but it's still aaaaugh worthy.

I also switched from staggered to diamond mapping for the tiles; diamond is actually more useful both for level editing and just to work with in terms of tile transforms and figuring out 'given x screen position, which isometric cell is it in?'. The isometric tilemap also supports visual and collision layers.



In a very ideal world I would find some way to optimise the colliders and merge them all together using Clipper or something (it's how Tiled2Unity does it) but that's a bit beyond my abilities at the moment. Plus it works and we're finally at a point where I can dev games instead of working on tools so :T.


Certain editor features were a bit of a pain. To clarify; collider points are stored in terms of pixels from the sprite's pivot, in texture space (origin 0,0 at bottom left)... but to display in the gui they have to be normalised, transformed into gui space (origin 0,0 at top left) and scaled and positioned... which is the space in which edits are made, which then have to be transformed back into pixel space, clamped to real values whilst not jamming up the mouse-click-drag operations and arfdjgfglbarsfdshargle... suffice to say numerous things went wrong in interesting ways whilst implementing the editor.

As it turns out I didn't need to faff around with generating textures from 3d models, I could just set up 3D models in the world if the spritemap was tilted to the appropriate angle.
To explain a little, the skewed coordinates the isometric map operates on basically defines a ratio between the z and y axes, where z is camera depth. To get 3D objects displaying correctly, you just have to rotate them 30 degrees in the global x-axis. So if you set up the ratio such that the tilemap is skewed by 30 degrees, the tilemap and 3D objects will happily play nicely with each other. There may be some edge-case sorting issues but I haven't run into any yet (admittedly the 3D character doesn't have any wild animations at the moment), and having full control over the sprites now I can actually mess with how depth is applied to the sprites and solve most issues. But that would be more tooling ( =_=)...

I also crashed together a quick cell-lighting shader for lighting 3D models, which you can see on the character. The character also snaps to 45 degree rotations when moving, mimicing the pre-rendered animations it is trying to mimic.

One visual glitch I did run into was a form of 'jittering' when the character was moving around. Even if not animating, the pixels would appear to jitter as the character moved. This turned out to be a result of interpolation; as the character's actual position was between screen pixels, the mesh would rasterize differently, causing the visual jitter. Snapping transforms to pixel coordinates in LateUpdate() solved the problem.

 

[bird_poison]

Okay, watching this.

 

[Guessmyname]

Hahahaha.

So you remember I mentioned a 'Boss Generator' in the Other Stuff I had lying around? I have it working now.

To clarify, I have been on-offing this thing for years. I think, three-four at this point? I had AI solved, visual bits and bobs solved, even a name generator I wrote in an afternoon in one version, but always, always the stumbling block has always been the animation.

The generator works essentially by slapping parts (limbs, heads, torsos etc) together and calling it a boss fight. It sources parts, textures etc from a primary and secondary 'Theme' collection, meaning you can wind up fighting a burning tree (fire + plant), a knight made of ice (ice + knight) and so on. Whilst it can assemble visually... interesting bosses well, actually animating them has always been more difficult. There is no traditional 'rig' or pre-made animations that can really be used; the boss is literally a jumble of parts it can't at all presume to know in advance. And you want these animations to be fluid, to look physically 'correct', often a part that's animating needs to pull on its parts and children and other such simulationist systems and... yeah, it's kind of complex.

There's been a dozen iterations on this generator, believe me (pictured: failure). Search my old posts in the chat lounge and you'll even find me talking about it. The later ones have always been purely focused on getting a boss animation system into place that actually works; this prototype is the same (literally; it is a hip piece with a single leg you can tell to sweep at a target by pressing 'K'). Where things differ here is in three key aspects:

1. Animation logic and visual part prefabs have been thoroughly decoupled. Animations are controlled by 'skeleton groups', which have no visuals of their own but contain all the controls their visual parts will use; "abstract boss parts", if you will. To give an example, the Limb Group contains an IK target for it's foot, and controls where this target goes, whilst the visual parts it can use will look up the target and use in whatever IK chain is appropriate. This means a boss can be described as 'a hip with some legs and a torso', with all the visual parts used to fill them in (Knight Hip, Knight Limbs, Tree Body etc) irrelevant. This required some means of visual parts telling the skeleton groups how big they are so that the animations can size accordingly, but it's worth it for how easy animation maintenance and tweaking will be. If I need to fiddle with an attack animation curve, I only have to edit it on the Limb Group, not every single limb prefab in every single Theme, which was a flaw in the first generator prototype. I expect to only have a few 'skeleton groups' (limb, head, hand, torso, various hip types etc...), which contain all their animation and AI logic, whilst the parts only have to deal with visuals and hitboxes.
   
2. ...Admitting I Cannot Complex Math and getting third-party solver tools for the splines and IK chains (Curvy and FinalIK respectively, if you're curious). I... attempted to write my own solvers in the past and. That isn't a happy place. Quaternions and the kind of errors that make Kerbal ragdolls look stable live there. It is not a happy place. Curvy and FinalIK have proven robust and reliable, Curvy in particular being very well suited for having its spline control points being existing gameobjects in the world; making ensuring attack animations reach their targets very simple. "I've just implemented it in an afternoon" tier simple, in fact.
   
3. I took the idea of the 'Rig controls' from more traditional animation and applied it to the animation of the bosses here. In 3D animation, you typically actually have a lot of extra controls (like, an object that a character's head is constrained to always look at, IK targets for hands and so on) that are not actually kept on animation export, they just help drive the bones of the rig and make the animator's life a lot easier. With the procedural bosses, the same applies; the skeleton groups have controls for the rig, but the actual 'bones' are in the visual parts, which follow the rig controls using their own configured IK chains and similar systems. This has the added advantage of not requiring bones match controls exactly; I'm making excellent use of springs to keep the visual motions fluid.

To be clear, this prototype is very hilariously cut down; there's no player, no combat system, it is literally a half-generated boss you can float around and tell to slap things like a lazy mechanical baby (I wish I could upload videos), but it works. The major hurdle, after years of attempts and frustration, is finally overcome.


(pictured: babby's first boss attack; a simple limb swipe from left to right)​

The game this whole biz is intended for, incidentally, is kind of like a procedural Zelda / Dark-Souls boss-rush in style. I'm taking visual cues from the Witches of Puella Magi largely because they're abstractly absurd monstrosities that are very well suited to procedural generation; the way the boss generator works by parts and themes means it could quite happily put you up against a tree in a suit of armour (Plant + Knight themes) but I'd never expect it to be able to build Kalameet or Artorias[1]​; abstract monstrosities suit it well because it can't make anything else. It rams parts together blindly with themes and tag searches; it is far too stupid to assemble a boss that makes coherent sense. What the actual setting/context for them and who the player is is kind of up in the air at this point. I only know the visual style will be Wind-Waker cell-shaded.

The idea is that the bosses are procedurally generated, yes, but because they're built of parts, you can actually break those parts off in battle. You can hack its legs off so it can only crawl after you, blind it by destroying its eyes, smash its weapons, cut/break the armour off its Boss Heart, which is the thing you need to break to kill it. The challenge is always 'get to and destroy the Boss Heart (without dying)', and the procedural generation ensures each fight will be wildly different in where the Heart is and how it's protected. I almost want to keep some of 'mana bar only refills when you defeat a boss' or similar mechanic ala grief seeds to encourage players to fight efficiently; taking the risk of not wearing the boss down to defeat it quicker and cheaper with the reward of having more mana to work with.

The AI for this nonsense, incidentally, is more of a solved problem. It's just Utility Theory. I can't build behaviour trees when I've no idea what actions a boss can perform in advance and the fights are too moment-to-moment for a GOAP planner to make any kind of sense, so it's just 'look at all the actions the boss can perform right now, pick whichever declares the highest "utility value"', where the 'utility value' is an attempt to assign a numerical value to how much of a good idea the action is right now. They're actually connected up to the animation sequences (since you can't really perform actions without one), and each action declares its own utility based on context. Where it gets even better is that I can actually tweak these per-boss with 'personality weights', such as highly aggressive personalities doubling the utility of attack actions, for instance. Difficulty can also be implemented here; easier bosses are less aggressive and telegraph their attacks more, etc.

The prototype itself needs a lot more work; there's no walk-cycling in the current version for instance and a bunch of other needed features to generate a 'proper' boss. My current goal is to be able to generate a 'complete' boss that can waddle around and gamely swipe at things with its legs... and then I want to be able to cripple it and hack legs off because i'm british that's a major feature past experience says takes some fiddling to implement well too. At that point though? Get a player and a combat system in there and you have a playable prototype, my friends! The second prototype I ever made for this actually got that far but for the animation, so with this hurdle passed it is definitely achievable.

I have been trying, pipe-dreaming and prototyping this damn thing for years, and it finally feels like it's getting somewhere. Just... yeah. Just wanted to post about that. Feels good man. Like, granted, half the reason it's taken so long is that it's A) ambitious as hell and B) requires a level of technical competency I just didn't have at the beginning (I had to learn to love work with Quaternions for this, which is part of why some older iterations completely fell apart), but still. I am officially Making Progress As A Games Developer if I can get this to work.

In other news, I have made considerable visual improvements to the hex maps (also with trees animated with vertex shaders in response to wind, sadly not pictured) and there's been some other shenanigans with the isometric pixel thing, though I'll probably drop that as my side project now the boss generator project has actual momentum.

[1] (Fire + Plant theme could make a way more entertaining Bed of Chaos, tho. Knight + Knight theme is pretty much the Iron Golem, too. Really though I wouldn't go full Dark Souls Bosses on this, given the odds of this becoming a Roguelike)​

EDIT: And praise to the mods for saving this post from accidental 'I thought I doubleposted' deletion @_@

 

[Look to the Left]

Hahahaha.

So you remember I mentioned a 'Boss Generator' in the Other Stuff I had lying around? I have it working now.

To clarify, I have been on-offing this thing for years. I think, three-four at this point? I had AI solved, visual bits and bobs solved, even a name generator I wrote in an afternoon in one version, but always, always the stumbling block has always been the animation.

The generator works essentially by slapping parts (limbs, heads, torsos etc) together and calling it a boss fight. It sources parts, textures etc from a primary and secondary 'Theme' collection, meaning you can wind up fighting a burning tree (fire + plant), a knight made of ice (ice + knight) and so on. Whilst it can assemble visually... interesting bosses well, actually animating them has always been more difficult. There is no traditional 'rig' or pre-made animations that can really be used; the boss is literally a jumble of parts it can't at all presume to know in advance. And you want these animations to be fluid, to look physically 'correct', often a part that's animating needs to pull on its parts and children and other such simulationist systems and... yeah, it's kind of complex.

There's been a dozen iterations on this generator, believe me (pictured: failure). Search my old posts in the chat lounge and you'll even find me talking about it. The later ones have always been purely focused on getting a boss animation system into place that actually works; this prototype is the same (literally; it is a hip piece with a single leg you can tell to sweep at a target by pressing 'K'). Where things differ here is in three key aspects:

1. Animation logic and visual part prefabs have been thoroughly decoupled. Animations are controlled by 'skeleton groups', which have no visuals of their own but contain all the controls their visual parts will use; "abstract boss parts", if you will. To give an example, the Limb Group contains an IK target for it's foot, and controls where this target goes, whilst the visual parts it can use will look up the target and use in whatever IK chain is appropriate. This means a boss can be described as 'a hip with some legs and a torso', with all the visual parts used to fill them in (Knight Hip, Knight Limbs, Tree Body etc) irrelevant. This required some means of visual parts telling the skeleton groups how big they are so that the animations can size accordingly, but it's worth it for how easy animation maintenance and tweaking will be. If I need to fiddle with an attack animation curve, I only have to edit it on the Limb Group, not every single limb prefab in every single Theme, which was a flaw in the first generator prototype. I expect to only have a few 'skeleton groups' (limb, head, hand, torso, various hip types etc...), which contain all their animation and AI logic, whilst the parts only have to deal with visuals and hitboxes.
   
2. ...Admitting I Cannot Complex Math and getting third-party solver tools for the splines and IK chains (Curvy and FinalIK respectively, if you're curious). I... attempted to write my own solvers in the past and. That isn't a happy place. Quaternions and the kind of errors that make Kerbal ragdolls look stable live there. It is not a happy place. Curvy and FinalIK have proven robust and reliable, Curvy in particular being very well suited for having its spline control points being existing gameobjects in the world; making ensuring attack animations reach their targets very simple. "I've just implemented it in an afternoon" tier simple, in fact.
   
3. I took the idea of the 'Rig controls' from more traditional animation and applied it to the animation of the bosses here. In 3D animation, you typically actually have a lot of extra controls (like, an object that a character's head is constrained to always look at, IK targets for hands and so on) that are not actually kept on animation export, they just help drive the bones of the rig and make the animator's life a lot easier. With the procedural bosses, the same applies; the skeleton groups have controls for the rig, but the actual 'bones' are in the visual parts, which follow the rig controls using their own configured IK chains and similar systems. This has the added advantage of not requiring bones match controls exactly; I'm making excellent use of springs to keep the visual motions fluid.

To be clear, this prototype is very hilariously cut down; there's no player, no combat system, it is literally a half-generated boss you can float around and tell to slap things like a lazy mechanical baby (I wish I could upload videos), but it works. The major hurdle, after years of attempts and frustration, is finally overcome.


(pictured: babby's first boss attack; a simple limb swipe from left to right)​

The game this whole biz is intended for, incidentally, is kind of like a procedural Zelda / Dark-Souls boss-rush in style. I'm taking visual cues from the Witches of Puella Magi largely because they're abstractly absurd monstrosities that are very well suited to procedural generation; the way the boss generator works by parts and themes means it could quite happily put you up against a tree in a suit of armour (Plant + Knight themes) but I'd never expect it to be able to build Kalameet or Artorias[1]​; abstract monstrosities suit it well because it can't make anything else. It rams parts together blindly with themes and tag searches; it is far too stupid to assemble a boss that makes coherent sense. What the actual setting/context for them and who the player is is kind of up in the air at this point. I only know the visual style will be Wind-Waker cell-shaded.

The idea is that the bosses are procedurally generated, yes, but because they're built of parts, you can actually break those parts off in battle. You can hack its legs off so it can only crawl after you, blind it by destroying its eyes, smash its weapons, cut/break the armour off its Boss Heart, which is the thing you need to break to kill it. The challenge is always 'get to and destroy the Boss Heart (without dying)', and the procedural generation ensures each fight will be wildly different in where the Heart is and how it's protected. I almost want to keep some of 'mana bar only refills when you defeat a boss' or similar mechanic ala grief seeds to encourage players to fight efficiently; taking the risk of not wearing the boss down to defeat it quicker and cheaper with the reward of having more mana to work with.

The AI for this nonsense, incidentally, is more of a solved problem. It's just Utility Theory. I can't build behaviour trees when I've no idea what actions a boss can perform in advance and the fights are too moment-to-moment for a GOAP planner to make any kind of sense, so it's just 'look at all the actions the boss can perform right now, pick whichever declares the highest "utility value"', where the 'utility value' is an attempt to assign a numerical value to how much of a good idea the action is right now. They're actually connected up to the animation sequences (since you can't really perform actions without one), and each action declares its own utility based on context. Where it gets even better is that I can actually tweak these per-boss with 'personality weights', such as highly aggressive personalities doubling the utility of attack actions, for instance. Difficulty can also be implemented here; easier bosses are less aggressive and telegraph their attacks more, etc.

The prototype itself needs a lot more work; there's no walk-cycling in the current version for instance and a bunch of other needed features to generate a 'proper' boss. My current goal is to be able to generate a 'complete' boss that can waddle around and gamely swipe at things with its legs... and then I want to be able to cripple it and hack legs off because i'm british that's a major feature past experience says takes some fiddling to implement well too. At that point though? Get a player and a combat system in there and you have a playable prototype, my friends! The second prototype I ever made for this actually got that far but for the animation, so with this hurdle passed it is definitely achievable.

I have been trying, pipe-dreaming and prototyping this damn thing for years, and it finally feels like it's getting somewhere. Just... yeah. Just wanted to post about that. Feels good man. Like, granted, half the reason it's taken so long is that it's A) ambitious as hell and B) requires a level of technical competency I just didn't have at the beginning (I had to learn to love work with Quaternions for this, which is part of why some older iterations completely fell apart), but still. I am officially Making Progress As A Games Developer if I can get this to work.

In other news, I have made considerable visual improvements to the hex maps (also with trees animated with vertex shaders in response to wind, sadly not pictured) and there's been some other shenanigans with the isometric pixel thing, though I'll probably drop that as my side project now the boss generator project has actual momentum.

[1] (Fire + Plant theme could make a way more entertaining Bed of Chaos, tho. Knight + Knight theme is pretty much the Iron Golem, too. Really though I wouldn't go full Dark Souls Bosses on this, given the odds of this becoming a Roguelike)​

EDIT: And praise to the mods for saving this post from accidental 'I thought I doubleposted' deletion @_@

Click to shrink...

Exactly how long have you been trying to make a decent prototype?

 

[Guessmyname]

Exactly how long have you been trying to make a decent prototype?

Click to shrink...

Well, I have posts about I think the third prototype somewhere in 2015? I have a blog post about what I was using for the character controller at one point from 2014 (which would be prototype two, which is where I first realised how much of problem animation would be). I kind of threw myself into it before I realised how much work it would be; the first prototypes actually focused on getting a third-person character running around, then the bosses.

This is something like the sixth or seventh iteration? I've somewhat lost track.

 

[Guessmyname]

Because obviously the first thing you do with a procedural creature design is 'make sure it can play football'. The sweep 'attack' will track to target, though it gets a bit funny when the target is too close / underneath the boss.

 

[Guessmyname]

So actual walkcycles are in now, along with 'copiers' (three of the four legs are actually copies of the first, because once more parts were added if there were just four different limb spawners you'd get four different limbs). The boss can move around with the legs coordinating with the hips to change their positions when they're in an invalid spot, whilst ensuring at least three feet are on the ground at a time and making the boss slow down to let the walkcycle keep in synch. Transitions into the attack animation are also nice and smooth; it's one my prouder features actually: any given action can smoothly interpolate into another; it only really looks weird if the actions are very different and the transition too fast.

Oh, and it can koolaid walls, which is always fun.

Position springs and interpolation is all well and good but the rig controls don't actually handle rotation all that well yet. I had a stab at using Unity rigidbodies for the rig controls (which would have given me rotation handling for free) but it came with a myriad of synching and control issues; the attack animation would almost never hit the target, for instance. Sssso I'm going to have figure out what the hell an "inertia tensor" is and write custom torque / rotation spring code.

Oh merry bloody joy.

This would have been a video with me jabbering over it, but it turns out my microphone is crap so gifs it is.

There are a few amusing edge cases at the moment; there's not 'falling' / 'air state' animation so the walkcycle kind of flails badly when the boss is falling through the air. It also has problems with thin walkways; the boss can technically move along them (there's an invisible capsule serving as it's actual movement collider) but the legs just give up crying because they can't find anywhere safe to place themselves.

After rotations are in, I'll work on limb loss.

 

[Look to the Left]

So actual walkcycles are in now, along with 'copiers' (three of the four legs are actually copies of the first, because once more parts were added if there were just four different limb spawners you'd get four different limbs). The boss can move around with the legs coordinating with the hips to change their positions when they're in an invalid spot, whilst ensuring at least three feet are on the ground at a time and making the boss slow down to let the walkcycle keep in synch. Transitions into the attack animation are also nice and smooth; it's one my prouder features actually: any given action can smoothly interpolate into another; it only really looks weird if the actions are very different and the transition too fast.

Oh, and it can koolaid walls, which is always fun.

Position springs and interpolation is all well and good but the rig controls don't actually handle rotation all that well yet. I had a stab at using Unity rigidbodies for the rig controls (which would have given me rotation handling for free) but it came with a myriad of synching and control issues; the attack animation would almost never hit the target, for instance. Sssso I'm going to have figure out what the hell an "inertia tensor" is and write custom torque / rotation spring code.

Oh merry bloody joy.

This would have been a video with me jabbering over it, but it turns out my microphone is crap so gifs it is.

There are a few amusing edge cases at the moment; there's not 'falling' / 'air state' animation so the walkcycle kind of flails badly when the boss is falling through the air. It also has problems with thin walkways; the boss can technically move along them (there's an invisible capsule serving as it's actual movement collider) but the legs just give up crying because they can't find anywhere safe to place themselves.

After rotations are in, I'll work on limb loss.

Click to shrink...

Is this how computers see?

 

[Guessmyname]

Is this how computers see?

Click to shrink...

Ironically enough, no. It's how I have to (try and) see to fix Whatever Is Inevitably Going Wrong Today. First rule of videogame consoles / debug modes; the amount of trouble the developer had with a feature is directly proportional to the amount of debug options exposed for it. It's gotten to the point I had to add a little debug controller that can turn debug drawing for certain features on and off to cut down the visual clutter.

Catching problems and solving glitches with running systems is a pain in the ass, especially if there's no easy way to breakpoint the problem and debug code the 'usual' way (for the non-coders; one of the most vital tools for debugging is the 'breakpoint', which marks a line of code and pauses the program when it reaches it. You can then step through your code line by line in the code editor and track what it's doing). It's a mix of debug drawing and having more variables exposed to Unity's inspector than is strictly necessary, just so I can keep tabs on what scripts are doing and try to analyse bad behaviour.

Classic example is how the visual body of the boss actually lags a little behind it's collider, because it's trying to keep its body over its center of mass as dictated by where it's legs are placed. Actually keeping the boss in synch with where it thinks its supposed to be is... interesting.

(Technically speaking though the boss is currently just using some copied code intended for character controllers rather than huge creatures. Keeping the pawn collider in synch with the boss itself shooouldn't be too difficult with some tweaking... he says, crossing a million procedurally generated fingers)

 

[Look to the Left]

Ironically enough, no. It's how I have to (try and) see to fix Whatever Is Inevitably Going Wrong Today. First rule of videogame consoles / debug modes; the amount of trouble the developer had with a feature is directly proportional to the amount of debug options exposed for it. It's gotten to the point I had to add a little debug controller that can turn debug drawing for certain features on and off to cut down the visual clutter.

Catching problems and solving glitches with running systems is a pain in the ass, especially if there's no easy way to breakpoint the problem and debug code the 'usual' way. It's a mix of debug drawing and having more variables exposed to Unity's inspector than is strictly necessary, just so I can keep tabs on what scripts are doing and try to analyse bad behaviour.

Classic example is how the visual body of the boss actually lags a little behind it's collider, because it's trying to keep its body over its center of mass as dictated by where it's legs are placed. Actually keeping the boss in synch with where it thinks its supposed to be is... interesting.

(Technically speaking though the boss is currently just using some copied code intended for character controllers rather than huge creatures. Keeping the pawn collider in synch with the boss itself shooouldn't be too difficult with some tweaking... he says, crossing a million procedurally generated fingers)

Click to shrink...

Glitches gonna glitch.

 

[Guessmyname]

Glitches gonna glitch.

Click to shrink...

Yeeeep.

Fun fact: the legs are connected to the body via simulated springs. Fun other fact: the first implementation of the walkcycle was actually too aggressive, and caused one leg moving to pull the rest of the body away from where it should have been.

Which then made all the other legs out of position, so they over-aggressively tried to find new locations, which pulled the body further from where it should have been, which...

Basically, you'd hit a key and the boss would start blindly stumbling around in wild circles. Hilarious and also very distressing...

 

[Look to the Left]

Yeeeep.

Fun fact: the legs are connected to the body via simulated springs. Fun other fact: the first implementation of the walkcycle was actually too aggressive, and caused one leg moving to pull the rest of the body away from where it should have been.

Which then made all the other legs out of position, so they over-aggressively tried to find new locations, which pulled the body further from where it should have been, which...

Basically, you'd hit a key and the boss would start blindly stumbling around in wild circles. Hilarious and also very distressing...

Click to shrink...

So a derp boss?

 

[Guessmyname]

Progress update!

Quaternion rotation springs are in (occasionally janky, but they're there and can be refined later), as is limb loss aaaand *drumroll*, the Black Hearts themselves!



Granted, all it does at the moment is sit there, beat and glow but this is the key part of the boss players will be aiming to destroy. Beat up and purify the Black Heart, and the boss is defeated! The trick is that they're well defended, and the boss will have a dozen limbs and turrets and other things to attack you with, so do you go straight for the Heart, or try to whittle it down first? Rewards are greater for an efficient takedown (ie you use up less magic in the process), but it puts the player at much greater risk.

The Black Heart itself provided an interesting problem for the boss generator; namely, the question of where to spawn it, given there's only supposed to be one per boss. Since the generator jams parts together based on tag searches (ie it initially searches for a hip, which then looks for a torso and some legs and so on) it is entirely possible for multiple 'candidate' heart locations to appear (or none, which is a real disaster scenario for the generator[1]​). This resulted in the creation of a secondary set of 'heart candidate' spawners; once all the boss parts are in place, it runs through the candidate heart spawns, picks one randomly and tells that to spawn the Black Heart, whilst all the others spawn a backup object. In the current generator there's only one part with a Spawner Candidate; the torso piece you can see there. If it isn't picked, it has an alternative front plate with no hole in it to spawn instead.

You may also note the little smoke puff when the leg is put back down! There is now a little event calling system built into the dynamic animation sequences, so it can call sounds and sfx at appropriate points (at start/end or at various points along the timeline). Further down the line this is how hitboxes will be turned on/off during attack animations, for example.

Currently, limb breakage is handled as ragdolling; the limb remains attached to the boss and is dragged after it. It can also be restored to a working limb again (this is all controlled by debug commands right now). What I'm planning is to build a distinction between 'disabling' a part (attached ragdoll; can potentially be restored by the boss later) and 'destroying' a part (literally severing it; boss cannot recover it / will have to expensively regenerate an entirely new replacement), but that will have to come later. Not all parts necessarily make sense for ragdolling either.

Break enough limbs and the boss falls down, becoming much slower to move, but unfortunately it looks a little crap at the moment; the way bosses move around is a standin and the hip piece doesn't really rotate to play nice with the legs; the end result is a mess, hence no gif. While it is pretty funny when a ragdolling limb manages to kick the physics object the boss follows around and send the whole ensemble magically flying, it's not what you'd call an intended feature...

As you might imagine, my next target is to rework the boss movement and the hip animation / walkcycle, learning from the issues inherent to the current one. I'm starting to think it might also be worth starting to prototype the actual player character and their control system. Boss Generation and Animation, the major hurdles, feel solid enough to work from at this point. Of mildly hilarious note is the sheer disparity in size between the player characters and the bosses;[2]​ the latter are big enough to be potentially valid level geometry to the former, which is going to be an interesting thing to mess about with. No Shadow of the Colossus style climbing mechanics are planned (I'm not that insane), but the player jump is intended to be both directed and pretty powerful; jumping onto a boss' face, melee-ing it and walljumping away is envisioned as a viable tactic, for example (it's an 'aim at the point you want to jump to' system; I had it implemented in a previous prototype).

[1] Ensuring there is always at least one candidate spawner will be a matter of future development. One way to work around it would be to ensure a 'failsafe' spawn location that every possible root part - hips, currently - must provide. As it stands, with the limited partset currently available, it is impossible for a zero-heart boss to occur. Worst case scenario it can scrap the boss, change the seed and try again but I'd really prefer to avoid that.
[2] Look at the tiny capsule marked 'TARGET' in the earlier gifs; that's the player size. I'm using "1 Unity Unit = Height of Player" as a general metric. To put this in perspective, each Knight Limb part is 8 Units long.

 

[Look to the Left]

Progress update!

Quaternion rotation springs are in (occasionally janky, but they're there and can be refined later), as is limb loss aaaand *drumroll*, the Black Hearts themselves!



Granted, all it does at the moment is sit there, beat and glow but this is the key part of the boss players will be aiming to destroy. Beat up and purify the Black Heart, and the boss is defeated! The trick is that they're well defended, and the boss will have a dozen limbs and turrets and other things to attack you with, so do you go straight for the Heart, or try to whittle it down first? Rewards are greater for an efficient takedown (ie you use up less magic in the process), but it puts the player at much greater risk.

The Black Heart itself provided an interesting problem for the boss generator; namely, the question of where to spawn it, given there's only supposed to be one per boss. Since the generator jams parts together based on tag searches (ie it initially searches for a hip, which then looks for a torso and some legs and so on) it is entirely possible for multiple 'candidate' heart locations to appear (or none, which is a real disaster scenario for the generator[1]​). This resulted in the creation of a secondary set of 'heart candidate' spawners; once all the boss parts are in place, it runs through the candidate heart spawns, picks one randomly and tells that to spawn the Black Heart, whilst all the others spawn a backup object. In the current generator there's only one part with a Spawner Candidate; the torso piece you can see there. If it isn't picked, it has an alternative front plate with no hole in it to spawn instead.

You may also note the little smoke puff when the leg is put back down! There is now a little event calling system built into the dynamic animation sequences, so it can call sounds and sfx at appropriate points (at start/end or at various points along the timeline). Further down the line this is how hitboxes will be turned on/off during attack animations, for example.

Currently, limb breakage is handled as ragdolling; the limb remains attached to the boss and is dragged after it. It can also be restored to a working limb again (this is all controlled by debug commands right now). What I'm planning is to build a distinction between 'disabling' a part (attached ragdoll; can potentially be restored by the boss later) and 'destroying' a part (literally severing it; boss cannot recover it / will have to expensively regenerate an entirely new replacement), but that will have to come later. Not all parts necessarily make sense for ragdolling either.

Break enough limbs and the boss falls down, becoming much slower to move, but unfortunately it looks a little crap at the moment; the way bosses move around is a standin and the hip piece doesn't really rotate to play nice with the legs; the end result is a mess, hence no gif. While it is pretty funny when a ragdolling limb manages to kick the physics object the boss follows around and send the whole ensemble magically flying, it's not what you'd call an intended feature...

As you might imagine, my next target is to rework the boss movement and the hip animation / walkcycle, learning from the issues inherent to the current one. I'm starting to think it might also be worth starting to prototype the actual player character and their control system. Boss Generation and Animation, the major hurdles, feel solid enough to work from at this point. Of mildly hilarious note is the sheer disparity in size between the player characters and the bosses;[2]​ the latter are big enough to be potentially valid level geometry to the former, which is going to be an interesting thing to mess about with. No Shadow of the Colossus style climbing mechanics are planned (I'm not that insane), but the player jump is intended to be both directed and pretty powerful; jumping onto a boss' face, melee-ing it and walljumping away is envisioned as a viable tactic, for example (it's an 'aim at the point you want to jump to' system; I had it implemented in a previous prototype).

[1] Ensuring there is always at least one candidate spawner will be a matter of future development. One way to work around it would be to ensure a 'failsafe' spawn location that every possible root part - hips, currently - must provide. As it stands, with the limited partset currently available, it is impossible for a zero-heart boss to occur. Worst case scenario it can scrap the boss, change the seed and try again but I'd really prefer to avoid that.
[2] Look at the tiny capsule marked 'TARGET' in the earlier gifs; that's the player size. I'm using "1 Unity Unit = Height of Player" as a general metric. To put this in perspective, each Knight Limb part is 8 Units long.

Click to shrink...

It's kinda starting to look like a boss now.

 

[Guessmyname]

'Still Alive' update: I'm currently working on the player character at the moment, which involves a lot of technical stuff that's hard to show off, particularly in regards to the animation architecture. One of the major weaknesses of Unity, especially as compared to UE4, is in its animation tools; in UE4 you get a whole visual scripting system that ties right into it, making modular animation sets a complete doddle to set up, and any specialised / procedural scripting (ie foot IK, or ensuring a third-person character is visually aiming at the correct point in space) neatly interwines. In my case, I want the player to have a variety of options as to weaponry, which naturally means different movesets. In UE4, this is simple. In Unity... this is not so much.

Unity's animation scripting tool is called Mechanim, and it's essentially a node-based editor for state machines, where a 'state' is a given animation. This is all nice and good, but it falls apart at the 'modularity' part: in the case of multiple movesets mentioned earlier, you'd have to include every single animation into the one AnimationController (Unity's animation state machine class). This induces a lot of bloat and having to build the same node sequence with different animations multiple times, making maintenance a complete chore (found a bug in a particular node sequence? Great! Now fix it and make the same change to every other time you used that sequence. Good luck remembering where they all were).

They do seem aware of this, introducing the (still experimental) Playables API, allowing you to blend AnimationControllers together and animate a single character using multiple controllers. The end result is the same level of functionality as the UE4 system... but without the aid of a node editor; everything has to be set up (and debugged...) via code. Which takes a bit of time. Communication between the AnimationControllers and my own CharacterAnimator is also tricky; it takes a few workarounds to let the AnimationControllers inform the CharacterAnimator when they've finished playing all their animations and need to stop playing.

I've got it roughly in place; the player can run around, jump and run, with animations and transitions. Falling through the air and running around on the ground are managed by two separate AnimationControllers, which is a bit excessive really but it let me test the system. In setting all this up and updating the movement code, it also became clear I'd need to separate the Character movement from the Procedural Boss movement; put simply Characters move first, then animate according to their movement, and the Procedural Bosses animate first, which naturally pulls them around and moves them. The latter proved necessary for bosses due to the unpredictability of the procedural movement animation; it kept causing a discrepancy between where the boss thought it was and where it actually was, visibly and physically. Now where it thinks it is is based on where it visually is, no there's no issues with desynching. I mentioned in an earlier post about how I'd have to redo the boss movement system at some point; wound up coming up earlier than expected.

It did mean I had to rewrite a lot of the procedural walkcycle code to get it running again properly though, and there's a number of edge cases that need to be solved (stick the boss under a low ceiling and it will warp up through it, for example); the end result isn't much different from what I've shown already, just less buggy in practise. For my own amusement, I actually set up the boss to chase the player around for kicks... which is how I managed to get on the leg, as in the above screenshot.

It's surprisingly intimidating being chased around by that thing; I'll need to make sure the camera can handle having bosses and players on screen at the same time. Think how Bloodborne/Souls adjusts the camera zoom/height when dealing with large bosses, for example.

No gifs at the moment, the character model is a standin and all their animations are just a few keyed poses hashed quickly together in Blender; aka 'janky as hell'. Still, it's progress.