Code for smooth FPS control with weapon attachment

Development
1

Hi all.
I am looking for some sample code for a smooth FPS control which I can use in my library.

The current one I have is based of the examples, however what is the preferred way to attach weapons to the player node which will point in direction of aim.

If anyone has some examples or code I can use as reference, it would be much appreciated.

2

There are a variety of ways to do this depending on what game you are trying to emulate or which limitations you are willing to accept.

3

Well I do not specifically want to emulate a game, I want to create a customizable control which I can use to create any type of first person game. For now, something similar to Firewatch.

But with the added behavior of attaching items to the player node, like arms, hands, weapons, etc.

I already have a control which works very nice, however when I move there are some sort of glitchy movement.

I have a suspicion it is the way the camera node gets updated to the position of the physics body.

4

I don’t think I have a single piece of code I can share, I don’t use controls for this and my architecture is probably very different of what you have. But I can comment some decisions that I took to make my fps movement that may inspire you. My reference game is Quake.

In my game the jme loop and game logic are in separate threads synced by message passing.
User input is read in the main thread and passed to the simulation thread, then a future frame (the next one at best) will be updated with the correct camera position. So the view is one step behind the simulation, however:

  • Mouse input updates the camera rotation instantly without waiting the simulation to be up to date. This makes it snappy and doesn’t feel sluggish, unlike movement which is conditioned by inertia and it doesn’t need to be as responsive.
  • I copied the player movement math from the original quake source. Here’s a good explanation.
  • The player physics object doesn’t have gravity, it just floats, then I calculate the acceleration and friction myself. Otherwise it was bouncy and jerky, specially when moving fast.

Also not related to movement but the weapon model is rendered on a different view port, this way I can have a three meter long rocket launcher and don’t having it clipped through walls.

5

Interesting using different thread for this.
Probably a better way to handle it rather than a normal Control attached to the player node.

I made a copy of the BetterCharacterControl as my base, and added camera look and movement behavior to it.

Thanks for sharing some thoughts on the subject.

1 Like
6

Some games use a screen overlay and the objects representing the player’s hands+gun are not even in the regular scene. Because it’s rendered over the top of the regular scene, it will never clip with walls… but it will also require its own lighting to be adjusted to where the player is standing.

Some games attach the arm/gun to the player’s chin. If they are suitably polished, they will detect when the gun is clipped with the scene and move them out of the way to avoid ugly clipped.

Some games use a combination of those two approaches. Where the object is attached to the player’s chin but still rendered as a completely separate layer.

Some games actually represent the player’s whole body. They can look down and see their hands/legs/etc… in that case it’s possible to just attach the weapons like any other object attachment. Just put them in their hands. However, this means that they will usually NOT be visible in the bottom of the screen like the typical chin-attached arm+gun. (The typical FPS style “gun always in view” like it’s attached to their chin is not realistic at all… it’s just a visual trick to help give the player diegetic status and some aiming capability.)

Really none of these will share code so trying to make something that “works for all FPSes” is a BIG job.

And yes, you will probably struggle with when the camera position updates with respect to when the weapon updates… one of the side effects of treating scene objects like game objects is that it’s very hard to control what the ‘current position’ is because it will change at different parts of the frame. (Where as architectures where the games objects are separate from the JME scene objects means it’s possible for the ‘game objects’ not to change during scene rendering.)

1 Like
7

Wow, so many tricks and solutions to this problem.
I never knew half of these, currently I am going for the see the full body of the player when looking down except the torso and head has been removed.
Something like this.

image
image1139×903 116 KB

Here I have just moved the player forward along the view direction, just to show the character.

1 Like
8

Well I found the glitchy camera problem.
I was making use of the spatial.getWorldTransaltion() instead of the physicsBody.getPhysicsLocation();

The physics location will almost always be one step ahead of the spatial position and it causes the glitchy camera movement.

1 Like