next »

[gimymblert]

He is talking about the navmesh implementation of unity, which handle everything you just said :D

[io3 creations]

He is talking about the navmesh implementation of unity, which handle everything you just said :D

I was talking about avoiding colliding with the wall.  The exact opposite of what the "Ghost Capsule" enemy did.

The awareness part seems to refer to being aware of the player's character, not the environment.

[gimymblert]

I know what I said

Agent Radius defines how close the agent center can get to a wall or a ledge.

https://docs.unity3d.com/Manual/nav-BuildingNavMesh.html

The Navigation Areas define how difficult it is to walk across a specific area, the lower cost areas will be preferred during path finding. In addition each NavMesh Agent has an Area Mask which can be used to specify on which areas the agent can move.

https://docs.unity3d.com/Manual/nav-AreasAndCosts.html

NavMesh Obstacle components can be used to describe obstacles the agents should avoid while navigating. For example the agents should avoid physics controlled objects, such as crates and barrels while moving.

https://docs.unity3d.com/Manual/nav-CreateNavMeshObstacle.html

[io3 creations]

I know what I said

Agent Radius defines how close the agent center can get to a wall or a ledge.

https://docs.unity3d.com/Manual/nav-BuildingNavMesh.html

The Navigation Areas define how difficult it is to walk across a specific area, the lower cost areas will be preferred during path finding. In addition each NavMesh Agent has an Area Mask which can be used to specify on which areas the agent can move.

https://docs.unity3d.com/Manual/nav-AreasAndCosts.html

NavMesh Obstacle components can be used to describe obstacles the agents should avoid while navigating. For example the agents should avoid physics controlled objects, such as crates and barrels while moving.

https://docs.unity3d.com/Manual/nav-CreateNavMeshObstacle.html

Ah! You mean the Unity Navmesh can do that!  Why didn't you say so?!  

Because the Navmesh that he was talking about and showing with gif clearly did not do that.     Yeah, communication is a tricky business.  Some things can be misinterpreted. 


(Obviously) I wasn't aware of that Navmesh feature, so thanks for mentioning that. 

Though, I'll just make my own navigation system because if all enemies follow the Navmesh then their movement could look uniform and predictble.  Plus, I'd like one that can be used by characters to deal with any type of surface (e.g. ceiling).

[Manaflow]

This looks pretty cool. I'm always a fan of good old rpgs. I like how you show the evolution of the character designs on the front page. Gonna be following this one.

[McMutton]

Though, I'll just make my own navigation system because if all enemies follow the Navmesh then their movement could look uniform and predictble.  Plus, I'd like one that can be used by characters to deal with any type of surface (e.g. ceiling).

You make a good point there, actually. I'll need to consider how to do navigation for flying enemies and stuff.

Thanks, ManaFlow- glad you like 'em!



Progress lately- I stumbled across an article about using Mecanim as a general-purpose state machine rather than just an animation one, so I thought I'd give it a try.

It's... It's like a whooooole new woooooorld! 


(If you aren't familiar with Mecanim, all of the hexagonal nodes also contain their own sub-state machines. MOAR STATES!)

Nothing is visualized at the moment- I'm currently setting up everything to run through the machine, making sure it all works as it should before I really get into it.

Super useful for dodge/jump canceling and combos and stuff!

[Chaoseiro]

Though, I'll just make my own navigation system because if all enemies follow the Navmesh then their movement could look uniform and predictble.  Plus, I'd like one that can be used by characters to deal with any type of surface (e.g. ceiling).

You make a good point there, actually. I'll need to consider how to do navigation for flying enemies and stuff.

Thanks, ManaFlow- glad you like 'em!



Progress lately- I stumbled across an article about using Mecanim as a general-purpose state machine rather than just an animation one, so I thought I'd give it a try.

It's... It's like a whooooole new woooooorld! 


(If you aren't familiar with Mecanim, all of the hexagonal nodes also contain their own sub-state machines. MOAR STATES!)

Nothing is visualized at the moment- I'm currently setting up everything to run through the machine, making sure it all works as it should before I really get into it.

Super useful for dodge/jump canceling and combos and stuff!

This... this is madness!!

(Could you kindly share this article? Thanks!)

[io3 creations]

Though, I'll just make my own navigation system because if all enemies follow the Navmesh then their movement could look uniform and predictble.  Plus, I'd like one that can be used by characters to deal with any type of surface (e.g. ceiling).

You make a good point there, actually. I'll need to consider how to do navigation for flying enemies and stuff.

Yeah, navmesh can be useful for pathfinding to get from A to B and can be updated with static object but the character still needs to be aware of other things.   

For example, once the character is close to it's target, it still needs to be know if a certain type of attack movement is possible by not colliding with other characters or the environment.  I've done some "basic" AI that can deal with such issues but want to make it into one that can deal with as many situations as possible.

(If you aren't familiar with Mecanim, all of the hexagonal nodes also contain their own sub-state machines. MOAR STATES!)

Nothing is visualized at the moment- I'm currently setting up everything to run through the machine, making sure it all works as it should before I really get into it.

Super useful for dodge/jump canceling and combos and stuff!

This... this is madness!!

(Could you kindly share this article? Thanks!)

Yep, if you're not careful you can end up with Mecanim Madness!

[McMutton]

It's too late... Mecanim Madness has already set iiiiiiin! 

Here's that article, Chaoseiro:
https://medium.com/the-unity-developers-handbook/dont-re-invent-finite-state-machines-how-to-repurpose-unity-s-animator-7c6c421e5785

[io3 creations]

It's too late... Mecanim Madness has already set iiiiiiin! 

Halloween season still lingers on.

[Ordnas]

Though, I'll just make my own navigation system because if all enemies follow the Navmesh then their movement could look uniform and predictble.  Plus, I'd like one that can be used by characters to deal with any type of surface (e.g. ceiling).

You make a good point there, actually. I'll need to consider how to do navigation for flying enemies and stuff.

Thanks, ManaFlow- glad you like 'em!



Progress lately- I stumbled across an article about using Mecanim as a general-purpose state machine rather than just an animation one, so I thought I'd give it a try.

It's... It's like a whooooole new woooooorld! 


(If you aren't familiar with Mecanim, all of the hexagonal nodes also contain their own sub-state machines. MOAR STATES!)

Nothing is visualized at the moment- I'm currently setting up everything to run through the machine, making sure it all works as it should before I really get into it.

Super useful for dodge/jump canceling and combos and stuff!

It is a nice idea to use Unity Mecanim as FSM for a character, but IMHO watch out that it is "risky" in a project: now the animation (what you see on screen) controls the Actor (the logic), while generally it is the Actor that has to implement the logic indipendently from what you see on the screen (the logic is indipendent from the rendering part).

Basically, now if you want to replace your Mecanim for your character, or just replace a single animation with a different timing, your actor will not work anymore as intended.

[McMutton]

Hopefully it won't be too much of an issue- The intent is to have the animation pretty much divorced from the state machine (at least directly- I use Legacy animations, so they aren't compatible with state motions, anyway).

This'll be used purely to shift between the various states depending on player input. The only thing that the animations will inform is the attack animations and their Windup-Active-Recovery states, as well as animation length for how long you get stuck in certain states.

It's actually running as a simulacrum of actual gameplay, at the moment, despite not having any animations attached to it- or even a character at all.

[McMutton]

Finally getting back into it!

Have some jumping and plunging attacks- though these are just rough placeholder animations for now.

(Click for GFY)

[gimymblert]

I'm super late in the navmesh stuff but to keep it short, all concern can be adressed because:
- you have a special raycast inside the navmesh space, cheaper than physic raycast, it adress knowing if your move will collide stuff.
- you can have multiple navmesh, and have them move relative to each other
- you can have navmesh in their own local coordinate, which mean ceiling and wall are navigatable.
- you can bake navmesh at runtime
- offlink is how you bridge different navmesh
- each object can have a specific navmesh (so flying don't have trouble)
- you can assign weight to navmesh region, they can be changed dynamically I think (need to check)
- If you are still bothered, you can still hijeck the data to build on top your own solution, like capturing the navmesh actual mesh data (vertex and polygon) or precompute waypoint path and baking them (which I might do for a fake town simulation procedurally generated, after generation time, to have npc routine to POI)

Assuming unity navmesh

[Ordnas]

Finally getting back into it!

Have some jumping and plunging attacks- though these are just rough placeholder animations for now.

(Click for GFY)

Very cool! 

[McMutton]

Thanks!

Doing this lady, too:

[Zaeche]

I love the cleanness of your 3D work! I like her design too 

I'm curious: do you use a rigging solution or prefer to slog through setting up the rigs manually?

[McMutton]

Hey, thanks!

Are Blender's Automatic Weights a rigging solution? Sometimes I'll use them to get a big chunk of it done, and then just refine it if need be with a really weak Add brush.

Other times I do cheat a bit by reusing already-rigged components from other characters. For her, I took the arms, hands, and base head from somewhere else, so they're already rigged up.

I sometimes model some sections using separate mesh pieces- this character's legs, for example, are made up of eight separate pieces, so rigging them up was super easy. Pretty much just getting a huge, full-weight brush and going over the piece, and then rig a bit of it to nearby bones if need be.

So it's mostly the latter, but I've found ways to make it a lot easier.

[McMutton]

Almost done

[io3 creations]

I'm super late in the navmesh stuff but to keep it short, all concern can be adressed because:
- you have a special raycast inside the navmesh space, cheaper than physic raycast, it adress knowing if your move will collide stuff.
- you can have multiple navmesh, and have them move relative to each other
- you can have navmesh in their own local coordinate, which mean ceiling and wall are navigatable.
- you can bake navmesh at runtime
- offlink is how you bridge different navmesh
- each object can have a specific navmesh (so flying don't have trouble)
- you can assign weight to navmesh region, they can be changed dynamically I think (need to check)
- If you are still bothered, you can still hijeck the data to build on top your own solution, like capturing the navmesh actual mesh data (vertex and polygon) or precompute waypoint path and baking them (which I might do for a fake town simulation procedurally generated, after generation time, to have npc routine to POI)

Assuming unity navmesh

Thanks for the notes.   
At this point, I'd say my system is working fine for me but I'll look into some of the points you mentioned since those might be useful in certain situations.