I just want to make sure I have this right!

News & General Discussion
1

My “learning” character is a walking robot - realistic with 6 legs and a tripod gait animation that I cooked up and imported from Blender.

I’ve gotten familiar with the Transform. calls and feel confident using them to move the model with Input.GetKey, I can play/stop animations (blend is still on the to-do) and control their playback speed. So far, so good!

Now I’m getting interested in really making my character control script more robust and complete. I intend to:

1.) Make the robot a kinematic rigidbody. Kinematic means it will not be impacted by physics itself, but rather the “faked” physics I design using Transform functions. It will still collide with non-kinematic physics objects.

1.) Use primitive colliders or generate an ultra-low poly mesh to use as a mesh collider, parenting that low-poly mesh collider to the robot.

If I did the second way, and made a low-poly mesh collider in Blender, would I give it a matching animation in Blender? As-is if I wanted pseudo-accurate collision (and I’m really doing this to learn) at least 12 primitive box colliders would be necessary.

Is this a proper or reasonable way to do this?

What about IK - does in-game real-time IK work with kinematic rigidbodies (I assume not)?

Just trying to be forward thinking and would like to hear, in Unity’s terminology, how you designed your character controllers; particularly non-standard ones (read: not a biped or “standard” vehicle).

2

Mesh colliders can’t be animated; it would be too slow.

–Eric

3

Thanks, noted… not surprised. Playing around with colliders and rigidbodies today it was all shockingly straight-forward. I will just parent primitives to the bones and design my character models to fit primitives well. Sometimes the simplest solution is the best one.

One important thing I didn’t get to test this evening: Can kinematic rigidbodies collide with each other? If not is there a common work-around, or are most characters in collision-heavy Unity games just using physics calls for everything?

I am planning 8-legged walking robots, so this would be very demanding. At the very least I would push them around on a few peg-stand colliders, and draw the leg colliders short of the ground so they aren’t the true points of contact.

Having the characters be able to push each other isn’t important for my design, I would rather discourage they “lock legs” in the first place if you will and simply having any enemy character be a brick-wall (that’s also trying to kill you) would feel natural enough.

Overall, massively impressed with how great Unity makes game development.

4

Kinematic rigidbodies can’t collide with each other, no. If you haven’t read it already, this page has useful collision/physics info.

–Eric

5

I’m wondering how player/player collision is typically implemented? Player characters are usually animated, often ragdoll… and collide withe each other. I assume animations aren’t exclusive to rigidbodies at the least.

The only other thing I can think of would be to have a duplicate rigidbody with a collider that isn’t in kinematic mode keep them apart.

6

Often, character controllers are used. From what you described it sounds like that would be sufficient. It’s not very common to have animated colliders, but if you wanted to accurately model individual legs colliding and so on, it would probably be best to use physics rather than a kinematic controller.

–Eric

7

When people say “character controllers” do they typically mean the default capsule character controller?

I was under the impression what I’m trying to script together is essentially a character controller.

I’ll plan on a physics implementation and start learning the associated function calls tomorrow, though.

8

Yes, Component → Physics → Character Controller.

–Eric

9

TL;DR there are no questions here, just goals. Written for myself as much as anyone curious.

Heh thanks- but gross, that will not work for me. I need a robust modular class that can accept inputs defined in another class (so the user can change their controls), from another class (so AI can control it), or the network (so someday a server could control it), or a separate local player. Additionally, player statistics will be maintained in an external class instantiated for each instance; and the UI will be an external singleton class that accepts inputs from multiple sources, one being the character controller. I’m big on the local second player at least, being far off from networking multiple camera objects shouldn’t be catastrophically difficult to implement, and PC game need more split-screen support. I intend to just include game elements that are “spray and pray like an idiot badly” and fun to use that a controller can get down on.

I approach this as a hobby but seriously, with the intent to design a reusable controller. It being modular also leaves room for more than one tank choice with each tank handling differently.

My specific outline design goals are:

(for the character controller)

1.) “Throttle” body acceleration and deceleration.
2.) Independent rotating lower body segment.
3.) Camera tracking mouse in a modeled “cockpit”.
4.) Turret view-port tracking camera at set speeds.
?.) Duration-raycast “locking” mechanic, though this may operate from a weapon class.

The camera will be in a (tiny) modeled dome structure with a couple struts and will have slightly more degrees of freedom than the actual turret for the player to look around a (tiny) cockpit with some canned animations that a “little grey man” body shown from first-person view will do with little alien hands in response to certain game events. Modeling this on a .1 scale should allow me to stick it inside a reasonably-scaled scifi-tank since this will probably just be a child not affected by physic.

Yes, there are a lot of potential problems.

(for the player-stats data object or class)

5.) Sectional damage model based on many hit-boxes.
6.) Logic calls to character controller which force fuckuppery upon the character controller based on that.
7.) Variable turret view-port tracking and movement speed based on weapon (and possibly tank) choices.

The game itself will accommodate every-other-level forked, standard-ish scene-per-level design controlled by a game manager and objective triggers in each level; like the layout seen in the classic “Star Fox”. Simple save-states will be level-based.

So, one goal → then the next strategy. I’ll be looking at some of my physics-based character controller examples I have today. I suspect what I am going to do is fake a simple ground-contact point invisibly under the legs, do everything in physics, and have the legs include only rudimentary bounding-box collision constraints (around all of them, rather than each). The advantage of using physics will be the ability to tilt the tank over uneven terrain more easily than I would have achieved with transforms (I was seriously considering a flat-world design strategy); the main disadvantage performance.

That is one thing I don’t know about game design: how truly powerful modern graphics cards and CPU’s are. It’ll be interesting to see at what point I run into performance issues with physics-based characters, but I think it should be doable because the game isn’t large in scope, there will probably be a dozen of these characters at once at maximum, and most collision data should be between them and the ground.