is UE3 right for me?

[andresch]

The UDK is an exciting opportunity, I hope it works out well for Epic.
I'm trying to make an assessment of the engine for a project; I would appreciate your opinions.
The game is a "third person slasher", you have a sword and try to hit the other networked players who are trying to do the same to you. The game is currently written in C++ using DirectX and PhysX. The characters are fully articulated rigid body simulations, animation data is used as input to the joint motors to make them move. This makes the character animate correctly but also the animation is correctly interrupted if the body parts or sword collide with something. PhysX collision data is used to calculate damage.
There are two special needs of the current implementation that I think may not align well with the UE3 engine:
1) Fine control over physics joint motors per time-step, with access into the animation hierarchy transformations. Is this type of thing possible inside unreal script? Does UE3 use PhysX for rigid bodies and joint/motors, or only integrate it in for advanced physics stuff? (like soft bodies and cloth)
2) The net-code for the current implementation is….nonstandard. Since the networked clients constantly and simultaneously affect the same physics simulation, typical client-side prediction strategies could not be used. The “snapping” caused by inaccurate predictions would be severe. Currently the player input is incorporated into the simulation only on the server side, essentially making a round trip before its effects are visible on the client.
Can you perhaps write some of your own net-code, like make your own UDP connection and send messages out of band with the engine’s implementation? Or something else I’m not thinking of?
Thanks for reading my long post.

[neai]

1) In general, yes. Do look into documentation and sources to see what's available.
2) Things like that can be done using built in net replication features. The easiest way might be to implement your players as vehicles.

Also, how do you handle physics tunneling issues?

[andresch]

Clearly I need to read the documentation, and I'm continuing to to that. I'm hitting roadblocks with the red underlined pages being unavailable, but making progress.
I'm intrigued by your suggestion to represent the player as a vehicle. How is that different?

[immortius]

Player characters in unreal have traditionally only used a single model and cylinder collision.
Vehicles however are composed of multiple parts connected via physics constraints (as far as I recall) and using more precise collision.

The latter sounds more suitable for your needs.

[neai]

Yea, typical players are basically cylinders run by hand-optimized set of physics modes like walking (stick to ground) or falling. The PhysX is used for ragdolls, like feign/death, or hit effects (motorized joints so it springs back to anim pose). The net code used for synchronizing client & server state of those special physics modes is non-trivial. The animation is driven by what is happening to the cylinder, not the other way around like in root motion.

Vehicles on the other side are by default proper physx-driven rigid bodies all the time.

What you want sounds like something between root motion and motorized ragdolls. Neither players nor vehicles provide that out of the box. If I wanted to start simple, I'd go with typical players and use physx just for hit detection. For full blown solution I'd start with vehicles or very modified players.

[LennardF1989]

I'd go with typical players and use physx just for hit detection.
Could you point that out for me please, fo my game the cylindercollision is just too inaccurate. Would this "PhysX Hit detection" help in shaping the collision box around a player (and thus also preventing him from "hitting BSP" when it shouldnt?).

Please ask if I'm unclear in my question.

[neai]

I mean, keep the cylinder for simplified movement collision, but use ragdoll/hitboxes for weapons.

[LennardF1989]

I mean, keep the cylinder for simplified movement collision, but use ragdoll/hitboxes for weapons.

Darn it :( I already have that, it almost sounded like something that would make the ragdoll model the collision-model, too bad...

[neai]

The optimized physics modes assume cylinder collision for movement. For full effect you'd probably need to ditch all that optimized pseudo-physics code and use full blown ragdolls & rigid bodies. This may require way more work.

The whole idea has two problems that need to be solved. First one is tunneling, collision primitives sometimes will move through each other or get stuck in each other. Typically you solve that with something like CCD. The other is characters getting stuck in each other or in level in physically accurate but annoying way. That's why you may want to use simplified collision for movement, physx or not.

[andresch]

i'd love to be far enough along to have to solve those two issues! A similar issue that plagues my current C++/directX/PhysX implementation is that fact that the spring/damper physX joints do not drive accurately enough to follow complex animations correctly. My swordsman looks like he's had way to much to drink. Spring/damper motors only work in very controled conditions with a lot of tuning. Unfortunatly velocity target motors are equally limited in that they only apply enough force to move the actor they are attached to, and do not account for other forces. (gravity, collisions with other actors)
The drunken swordsman problem exists either way, but if I can get back to it after porting to UDK at least I won't have to use my home-grown netcode, rendering, production pipeline, etc. and instead use a proven stable engine. Maybe by then PhysX will have a better joint motor option....
I believe the solution to the joint motor problem can be found in ODE. (ode.org) they implemented their velocity target motors as constraints in the solver, which means they accuratly drive to the desired velocity accounting for all external forces impacting the actor. if anyone knows how to get a feature request to the right person on the PhysX team pass that along!

[Blade[UG]]

Seems like it might be possible to use the regular cylinder for the main body, and then attach extra components to the arms and head to use seperately. A bit of a hybrid system. I've often considered that possibility, but haven't got aroudn to implementing it in anything. It seems like there's just way too much junk in the UTGame that needs to be removed to get it to work, and the basic Game doesn't even function.

[Kohan]

This game of yours sounds top-notch. Do you have a website for it I can take a look at?

[andresch]

Top-notch? um, no. The whole thing is available in the codeplex project: http://www.codeplex.com/BMD3

Building the source that's out there right now might be more trouble than it's worth, it uses old-ish versions of the DX and PhysX SDK's. Basically there are a couple things about it that I think are unique and may be interesting to take and use for yourself.

Control scheme: direct control over mele combat mechanics. There is a horrible doc on the codeplex site that tries to explain it.
Netcode: by assuming LAN use I scraped client-side prediction and have a multiplayer game with physically simulated player characters that collide with each other. "physical interaction" between networked players is rare because of the "snapping" that comes from client-side prediction.