Character Movement UE4 Roadmap items

Development Programming & Scripting C++
, , ,
1

Hi all,

there are some items on the UE4 roadmap that I’d like to work on. For example:

  1. Gameplay => Sphere/Box support for Character Movement
  2. Gameplay => CharacterMovementComponent on any Pawn

Questions:
a) Is it in general ok to start working on roadmap features?
b) To avoid duplicate work, is anybody else working or will work soon on these features?
c) Could somebody from Epic please discuss them with me to agree on an acceptable implementation?

Thanks,

2

Hi there ! Sorry for the late response, I was out for extended sick leave after surgery when this thread came up and I lost track. To answer your questions:

Always encouraged! But it’s best to reach out to make sure it’s not already in progress (as you are doing and mention in your next point).

Not that I know of. The major items we are certainly planning on for the nearish future are:

  1. Improvements to character movement replication (integrate UT improvements)
  2. Arbitrary orientation/gravity direction for characters (there is a GitHub pull request already for this)

I’m happy to get the discussion going.

Sphere should really be supported already, since it’s a special case of a capsule, but there may be some bad assumptions about there always being a height in addition to the end caps.

The first step is identifying which code relies specifically on aspects of the capsule, and then how we could possibly abstract that out for more general implementation. Hopefully some of the code can just use based ShapeComponent functions, but there are some places that work specifically with radius and half-height that need to be more general… that might require a switch() on the shape type, or some other approach.

I think most people using Box would be using it with a fixed rotation (ie 2D sidescroller). That might be a fair assumption that would make the code simpler. Supporting arbitrary orientations is great (and is part of the gravity change), but I’m not sure if that applies here. You might want to check out that pull request and work off that or at least consider how it could be made compatible as well (since they will likely merge at some point with this change).

This one is tricky, because it’s a pretty big refactor of existing code that has the potential to affect a lot of existing users. There are assumptions such as GetMesh() never returning false, some replication data that lives on Character, some virtual overrides (some blueprint overrides as well) that could be broken… etc. This is the main reason we’ve held off on tackling this. Almost all of those replicated properties could probably move to the CMC instead, that wasn’t done because components used to not support replication. Additionally components were not always blueprintable, so BP hooks also lived on Character. Blueprint events could also be moved to the component now, but that would break all existing character blueprint overrides, and CMC is not blueprintable.

Whenever we’ve discussed this internally we’ve usually leaned towards making a CharacterMovementV2 (or AvatarMovement or whatever) and CharacterV2 (or Avatar, or make base Pawn compatible without needing this) and started fresh with something cleaner so as to not break existing code. Then we would deprecate (or just not support after some time) the original version. This “V2” would most likely contain all the replication data needed, all BP events, avoid capsule-only assumption, and support arbitrary orientation. Ideally it would not be hard to migrate to this from an existing Character/CMC setup, but automating that is probably out of scope.

I’m happy to continue discussion and interested to hear any other feedback or ideas.

3

Hi, Zak & , a little late to the party but I just wanted to know if this so-called CharacterMovementV2 ever made it off the ground? Would be very interested in checking out any alpha- or beta-quality code even.
Cheers,
Dave

4

It’s something we’d like to do, but not currently scheduled.