I’m currently working on a fighting game engine, and I want to have a high degree of control over how the fighters move, including custom jump behavior. I started working with a Character actor, however, I quickly found that the pre-built physics functionality was getting in the way of how I want the fighters to move, so I did some deeper digging into how to build a character from scratch. The conclusion that I kept coming to is that not only does Unreal Engine make it incredibly difficult to do character movement without their build-in component, but there are also very limited (useful) resources as to how to build characters without using their component.
I’m currently attempting this by using Pawn actors, and an Add Movement Input node running each tick to do physics calculations (which, of course works on my Character object, but despite the fact that it is reading inputs, the same code is currently not working with the Pawn actor).
I have a programming background, and have done character implementation in various other engines, so programming the physics / logic from scratch in either Blueprints or C++ are hurdles that I am prepared to overcome. Does anyone here have any resources or advice as to how to go about developing a character object from scratch?
I kept coming to is that not only does Unreal Engine make it incredibly difficult to do character movement without their build-in component
You got the general idea correct. But it should be noted that the problem is only limited to CharacterMovementComponent that only an ACharacter have. So, the decision to start from APawn is correct.
Add Movement Input node running each tick to do physics calculations (which, of course works on my Character object, but despite the fact that it is reading inputs, the same code is currently not working with the Pawn actor).
The only thing you missing is… the MovementComponent, the piece of code that tranform your inputs into actual location changes.
The simple solution would be to add FloatingPawnMovement component that iirc implements the simplest movement in 3d space: just location changes, no gravity, no collision checks, no networking - nothing else. I’m not sure how it’s integrates with AddMovementInput() node you mentioned, so you should check it yourself
The bit harder solution would be to write custom movement component from the scratch:
You may integrate it into AddMovementInput() workflow or use the player inputs directly and make your own;
The core idea is to check your inputs on tick and make SetActorLocation() based on it.
Thing that should be stressed: only CharacterMovementComponent have out-of-the-box support for proper networking of actor’s movement, plus bunch of other nice things.
If you making singleplayer game it’s fine to make your custom solution;
If you aiming for multiplayer, assuming having no realtime game networking background - be ready to spend a month or few before you get any tangible result.
And another thing to be noted: engine sources are open, so you may look into how each feature is implemented, including default movement components, pathfinding, pathfollowing, input, etc.
The core idea is to check your inputs on tick and make SetActorLocation() based on it.
Yes–that’s exactly what I was missing! I had been using AddMovementInput(), completely forgetting that SetActorLocation() was a function available to use. Replacing the logic using the Movement Component function did the trick, and the Pawn is working as expected. Thank you very much for that suggestion!
Additionally, you cautioned that the CharacterMovementComponent came with out-of-the-box networking support, while custom Pawn objects do not. This project is intended specifically for local multiplayer, with online multiplayer likely being way out of scope. In the event that online multiplayer is never a concern with this project, are there any other pitfalls I should be wary of when implementing two custom player Pawns, specifically for local multiplayer?
Cheers, my friend, you’ve saved me a heck of a headache.
In case of local multiplayer this warning is irrelevant: from the point of movement, when the things happens only on single computer - it’s the same as singleplayer game, and solution is as simple as SetActorLocation() on tick.
Also no additional pitfalls i can think of right now