Adding vehicles

[Stoo]

So I've been trying to work out the best way to implement vehicles in this engine, and the most relevant thread I've been able to find - http://www.cafu.de/forum/viewtopic.php? ... &view=next - is from 2008, so I thought it better to start a new topic to ask for clarification rather than raise a zombie thread

The overall method that I've been looking at, largely based on what I understood in that thread, is to have the player switch to a new "piloting" state of existance when a vehicle is entered. Basically, when a vehicle is boarded, the HumanPlayer takes on the characterstics of the target vehicle (model, position & rotation, max speed, health, armor, bounding box & physics...), and the camera position changes to reflect the size of the player-vehicle. The vehicle entity is removed from the world, and the player replaces it, all (hopefully!) seamlessly. Player controls would then be processed by a new player state branch in Think(). When a player disembarks, all these changes are reversed, and the vehicle entity is dropped back where the player's current position is, and the player's position is adjusted to something reasonable.

My main concern is that this seems a bit overcomplicated and inflexible. Would it make more sense to have the piloting state indicate that all control updates (and camera POV) should be applied to the player's piloted vehicle entity, and that the actual HumanPlayer entity should be removed from the world? Can the camera and controls be decoupled this way? Or is there a better way I'm not seeing?

[Carsten]

The overall method that I've been looking at, largely based on what I understood in that thread, is to have the player switch to a new "piloting" state of existance when a vehicle is entered. [...]

Yes, that is a correct summary of the suggestion in the old thread.

My main concern is that this seems a bit overcomplicated and inflexible. Would it make more sense to have the piloting state indicate that all control updates (and camera POV) should be applied to the player's piloted vehicle entity, and that the actual HumanPlayer entity should be removed from the world? Can the camera and controls be decoupled this way? Or is there a better way I'm not seeing?

Well, unfortunately, I've never (or better: not yet) tried to implement vehicle support myself, so I cannot tell for sure if the original suggestion is sound, or if there are better alternatives.

One aspect is that - in the original suggestion - I'd consider the EntHumanPlayerT class less like the human player as it is now, into which the vehicle code is squeezed besides the normal code, but rather only as a "proxy". This proxy would

• forward all functionality to e.g. WalkingHumanPlayerT if the player is on foot, which would work very much like the existing EntHumanPlayerT class now,
• and forward all functionality to e.g. DrivingVehicleHumanPlayerT if the player is sitting in the car and driving.

This is what was meant in the brief reference to the State design pattern in the 2008 thread. (The GoF book has a better description for it: "State allows an object to alter its behavior when its internal state changes." and "it looks as if the object has changed its class".)

Another aspect is that an approach like this would be simple in the sense that it saves the rest of the engine from knowing that the human player should be a different entity instance when he enters/leaves a vehicle.

And third, implementing all this is possible only since http://trac.cafu.de/ticket/113 made such good progress in the past few weeks. This ticket too will see more work very soon, but the basis for implementing things is already there. I'll next finish the (closely related) scripting improvements, then get back to it.

[Stoo]

One aspect is that - in the original suggestion - I'd consider the EntHumanPlayerT class less like the human player as it is now, into which the vehicle code is squeezed besides the normal code, but rather only as a "proxy". This proxy would

• forward all functionality to e.g. WalkingHumanPlayerT if the player is on foot, which would work very much like the existing EntHumanPlayerT class now,
• and forward all functionality to e.g. DrivingVehicleHumanPlayerT if the player is sitting in the car and driving.

This is what was meant in the brief reference to the State design pattern in the 2008 thread. (The GoF book has a better description for it: "State allows an object to alter its behavior when its internal state changes." and "it looks as if the object has changed its class".)

Okay, so if I understand you right, you're suggesting splitting the current HumanPlayer class into two classes - one that represents the player in the world and handles all physics and world interaction, and is rendered on everyone else's clients (your WalkingHumanPlayerT, which sounds like what I've heard called an avatar elsewhere), and one that receives user input and tracks the state of the user aspect of the player (which avatar is in use, score, etc.) Then when the player jumps in a vehicle, the avatar disappears for a while, and the vehicle receives all movement commands; until the player jumps back out and the avatar pops back in and starts receiving commands again.

That is definitely a lot more flexible, and makes a lot more sense to me from a design perspective... but is also a lot more complex to code On the other hand, it'd get some other functionality for free - another piece that I was hoping to add in down the line was to be able to switch which character in your party you're controlling - particularly if you become a casualty. It sounds like this would get me that for free And the vehicle piece is central to my project, so it's worth the time taken on it

And third, implementing all this is possible only since http://trac.cafu.de/ticket/113 made such good progress in the past few weeks. This ticket too will see more work very soon, but the basis for implementing things is already there. I'll next finish the (closely related) scripting improvements, then get back to it.

Like I said elsewhere, I'm on your last stable release still - I'll have to get into the SVN version and see your latest changes.

[Stoo]

I'm still trying to figure out how to split out the player input handling section from the HumanPlayer code... what actually captures keyboard inputs? It looks like every HumanPlayer instance looks at what PlayerCommands the server has sent out, rather than what's happening to the keyboard...

[Carsten]

Hi Stoo,

I'm still trying to figure out how to split out the player input handling section from the HumanPlayer code... what actually captures keyboard inputs? It looks like every HumanPlayer instance looks at what PlayerCommands the server has sent out, rather than what's happening to the keyboard...

Yes, that's right: the player commands are assembled by the client (ClientStateInGame.cpp), which sends them to the server and stores them for local client prediction.

The current system is not ideal (unfortunately, we cannot send the raw key codes to the server, the mapping from key code to game function must be done by the client), but it should be relatively easy to extend. (It would be ideal of course if we made the key-to-function mapping user configurable...)

[Stoo]

Yes, that's right: the player commands are assembled by the client (ClientStateInGame.cpp), which sends them to the server and stores them for local client prediction.

Okay... so where would the "redirecting" class fit into the flow? It sounds like something needs to happen server-side to determine whether the keystrokes go to the humanplayerentity or the vehicle instance on the clients... Even more, it sounds like it may be needed on the client as well, for proper prediction. Or does the ClientStateInGame determine where key commands go somehow?

I was a bit surprised that you pass player inputs from the server out to the client classes... I figured that you'd have the client translate the commands into intended movements, pass that to the server, and let it determine whether the movement update was allowed before passing it on to the other clients. Y'know, in all my experience writing FPS engines

[Carsten]

Okay... so where would the "redirecting" class fit into the flow? It sounds like something needs to happen server-side to determine whether the keystrokes go to the humanplayerentity or the vehicle instance on the clients... Even more, it sounds like it may be needed on the client as well, for proper prediction. Or does the ClientStateInGame determine where key commands go somehow?

No, it's much easier than that:
You need to be concerned about player commands only in the human players Think() method (as it is now / in DeathMatch MOD).

The Think() method for human players is called on the server, as well as on each players local client for prediction, as appropriate.

In your case, the original EntHumanPlayerT would take the role of the "redirecting" class (EntHumanPlayerThatCanWalkAndDrive ), and it would contain the new, true walking and driving classes.

(The ClientT in http://trac.cafu.de/browser/cafu/trunk/Ca3DE/Client is structurally similar to this: Depending on it's state, it redirects method calls to a contained instance that actually handles the call. The ClientT however releases and reallocated its states as needed; a feature that is probably not necessary in your case.)

I was a bit surprised that you pass player inputs from the server out to the client classes...

This isn't the case: Player commands are processed on the local client where they were created (for prediction), and on the server (for moving the authoritative player instance). In both cases, the Think() method does the actual work.
Only the finished player state, like the state of any other entity, is distributed back to all connected clients.

I figured that you'd have the client translate the commands into intended movements, pass that to the server, and let it determine whether the movement update was allowed before passing it on to the other clients. Y'know, in all my experience writing FPS engines

Well, that's pretty much like it works.
The intended movements are in struct PlayerCommandT, and used in that form for both local prediction as well as processing on the server.
When the server sends the resulting state of the human player back to all connected clients, and the local client finds that the server computed a different result than what was locally predicted, the locally predicted result is replaced by the servers.

[Stoo]

No, it's much easier than that:
You need to be concerned about player commands only in the human players Think() method (as it is now / in DeathMatch MOD).
...
In your case, the original EntHumanPlayerT would take the role of the "redirecting" class (EntHumanPlayerThatCanWalkAndDrive ), and it would contain the new, true walking and driving classes.

Y'know, that's pretty much what I thought needed to happen originally... then I thought it might be slightly more complicated, so I started tracing code to make sure that was the case, rather than just trying it... then lost track of it in the first place

When the server sends the resulting state of the human player back to all connected clients, and the local client finds that the server computed a different result than what was locally predicted, the locally predicted result is replaced by the servers.

So, since the redirect happens in the Think method, it happens both in the clients and on the server, correct? So would the vehicle also get any kind of position updates on the different clients directly from the server? Is there any chance that a client somehow misses a few command updates, and the vehicle on that client starts "drifting" from where the server thinks it is?

Also, how would I adjust the camera to render from the vehicle, rather than where the player switches to "driving" mode? I've had some... amusing results from experimenting with this (shot through the map's roof at one point ), but I haven't puzzled out how it should actually work.

[Carsten]

So, since the redirect happens in the Think method, it happens both in the clients and on the server, correct?

Yes.
Although I think that you need to think about the Think() ( ) method only as if it was running on the server only:
The Think() method "transfers" an entity from one state to the next.
Human player entities are special mostly because their thinking is not driven by the frame time, but by the incoming player commands.

So would the vehicle also get any kind of position updates on the different clients directly from the server?

Yes.

Is there any chance that a client somehow misses a few command updates, and the vehicle on that client starts "drifting" from where the server thinks it is?

Non-local clients (the other players you see running or driving around) are, for your local client, just like any other server controlled entity: They're updated via the same networking mechanism / type of network messages (not via player commands).

Your local client uses player commands for prediction (in Think()), and sends them to the server, also for Think(). The server then sends the result of your local client back to you in regular network messages, just like for any other non-local client or monster.
Any "asynchronity" that may occur during this process is automatically and properly handled. (In short, if the servers authoritative data is different from what or where the client thinks it was at the time the servers data is for, it corrects the matter by re-applying the player commands from the time in the past the server sent authoritative data for. This is called re-prediction. It's implementation in Cafu is very robust and reliable, I'm quite proud of it. )

Also, how would I adjust the camera to render from the vehicle, rather than where the player switches to "driving" mode? I've had some... amusing results from experimenting with this (shot through the map's roof at one point ), but I haven't puzzled out how it should actually work.

Well, I'm not sure how to answer this best, but in the mental model above, where the player internally changes state between walking and driving, the player "becomes" the vehicle when he enters it.

Maybe it helps to think not of a vehicle, but of a jetpack: As soon as the player picks up the jetpack (enters the vehicle), its internal state changes (fly/drive mode instead of walking), with side effects like different physics (jetpacks are flying, vehicles driving, ...), modified head-up-display for flying (or the armatures of a car), and the players model visible to other players changes as well (has the jetpack on the back, or the vehicle all around him).

I admit it's a far shot, but does that provide some answer to your question?


Also, something else:
When I recently started some improvements to the Scripting system, my intention was to only make a short diversion from my current mission (improving the game code), and to return to it quickly, so that I can better help you with your questions and possibly work towards a vehicle sample implementation.

Unfortunately, the Scripting improvements turned out to be a lot more complicated than expected, and took a lot more time. Good news is that it's almost done now, all the brainteasers and cruxes are implemented in the latest revision. (If you're interested, see the UniScriptState.* files in http://trac.cafu.de/browser/cafu/trunk/Libs for details.)

I still need at least the upcoming weekend to finish this up, but then will return to improving the game code. This in turn is subdivided into several sub-items, but I'll focus on the HumanPlayerEntT first (and possibly try implementing some vehicle code, too ). In any case, my (main and/or side) goal would be to make both the implementation of vehicles easier, and to put myself into a position to provide firmer answers to the topic.

[Stoo]

Although I think that you need to think about the Think() ( ) method only as if it was running on the server only:
The Think() method "transfers" an entity from one state to the next.
Human player entities are special mostly because their thinking is not driven by the frame time, but by the incoming player commands.
...
Non-local clients (the other players you see running or driving around) are, for your local client, just like any other server controlled entity: They're updated via the same networking mechanism / type of network messages (not via player commands).

Your local client uses player commands for prediction (in Think()), and sends them to the server, also for Think(). The server then sends the result of your local client back to you in regular network messages, just like for any other non-local client or monster.
Any "asynchronity" that may occur during this process is automatically and properly handled. (In short, if the servers authoritative data is different from what or where the client thinks it was at the time the servers data is for, it corrects the matter by re-applying the player commands from the time in the past the server sent authoritative data for. This is called re-prediction. It's implementation in Cafu is very robust and reliable, I'm quite proud of it. )

That makes a lot more sense... I do have a tendency to overthink the thinking thoughts I thought you were saying that everybody heard and processed everyone's keystrokes, which struck me as... ineffecient. I get it now.

Maybe it helps to think not of a vehicle, but of a jetpack: As soon as the player picks up the jetpack (enters the vehicle), its internal state changes (fly/drive mode instead of walking), with side effects like different physics (jetpacks are flying, vehicles driving, ...), modified head-up-display for flying (or the armatures of a car), and the players model visible to other players changes as well (has the jetpack on the back, or the vehicle all around him).

I admit it's a far shot, but does that provide some answer to your question?

...and now I'm confused again

I thought you were saying that the HumanPlayerEntity should go into "piloting" mode, and then render on other clients similarly to when in pre-spawn mode; ie, not at all. Instead, all command updates would get passed along to the vehicle class, which would then translate them into move/attack updates for the vehicle - this way, the HumanPlayerEntity just needs a simpler "piloting" mode defined to pipe commands to the vehicle, and different vehicles can then roll/fly/stomp/whatever else they should do.

To use your jetpack example, I thought a player would "pick up" the jetpack, turn invisible/intangible, and then... control it by remote? In this case, I'm stuck on how to add a camera to the remote I hadn't planned to bother rendering the player in the vehicle, for simplicity - the vehicles in general are big enough you can't really see the pilot anyway. I could just stick the controlling HumanPlayerEntity wherever the vehicle is, but it seems like that could lead to other issues down the line. But, if the player entity itself doesn't directly interact with the world at all, I guess it wouldn't really matter...

...modified head-up-display for flying (or the armatures of a car)...

Are you still talking about the local HumanPlayerEntity when you talk about the player in your jetpack analogy? Or is it intended to be more of a description of how the gameplay would "feel" to the user? I don't remember seeing UI code in that class, but I haven't been able to play with it much in the last week...

Also, something else:
When I recently started some improvements to the Scripting system, my intention was to only make a short diversion from my current mission (improving the game code), and to return to it quickly, so that I can better help you with your questions and possibly work towards a vehicle sample implementation.

Unfortunately, the Scripting improvements turned out to be a lot more complicated than expected, and took a lot more time. Good news is that it's almost done now, all the brainteasers and cruxes are implemented in the latest revision. (If you're interested, see the UniScriptState.* files in http://trac.cafu.de/browser/cafu/trunk/Libs for details.)

This is going to require its own reply, after I've had time to look at it more... I look forward to more script functionality, though! Any chance of a preview of your HumanPlayerEntity changes?

(and possibly try implementing some vehicle code, too )

Gah, don't tease me like that! I'm mainly interested in creating an RPG ruleset in script; I'm just messing around in code because vehicles are essential to my concept. But I'm sheltered, and used to a more managed environment... so C++ isn't the most relaxing way to spend my free time!

But if you were planning to add something in anyway...

[Carsten]

...and now I'm confused again

I thought you were saying that the HumanPlayerEntity should go into "piloting" mode, and then render on other clients similarly to when in pre-spawn mode; ie, not at all. Instead, all command updates would get passed along to the vehicle class, which would then translate them into move/attack updates for the vehicle - this way, the HumanPlayerEntity just needs a simpler "piloting" mode defined to pipe commands to the vehicle, and different vehicles can then roll/fly/stomp/whatever else they should do.

To use your jetpack example, I thought a player would "pick up" the jetpack, turn invisible/intangible, and then... control it by remote? In this case, I'm stuck on how to add a camera to the remote I hadn't planned to bother rendering the player in the vehicle, for simplicity - the vehicles in general are big enough you can't really see the pilot anyway. I could just stick the controlling HumanPlayerEntity wherever the vehicle is, but it seems like that could lead to other issues down the line. But, if the player entity itself doesn't directly interact with the world at all, I guess it wouldn't really matter...

Well, yes, that's true:
Before the player enters the vehicle, we have two distinct entities: the player and the vehicle.

When the player enters the vehicle, it must internally change its "state" as discussed earlier, which only means that it now has to do something else with the player input than before, namely process vehicle physics rather than walking physics.

It's difficult to say, and all very theoretically, without a concrete example, which of the two entities - if any - should be made "invisible" and how exactly the two entities should be kept in sync during the tour...

But I'm sure things will fall into place once they're implemented.

...modified head-up-display for flying (or the armatures of a car)...

Are you still talking about the local HumanPlayerEntity when you talk about the player in your jetpack analogy? Or is it intended to be more of a description of how the gameplay would "feel" to the user? I don't remember seeing UI code in that class, but I haven't been able to play with it much in the last week...

Yes, I was talking about the HumanPlayerEntity code, what that code had to accomplish when the EntHumanPlayer was in jetpack (or vehicle) mode...

This is going to require its own reply, after I've had time to look at it more... I look forward to more script functionality, though! Any chance of a preview of your HumanPlayerEntity changes?

There is nothing that I've prepared yet, all my time was spent with the scripting stuff.

Btw., do you happen to have a car model that I could use for testing?

(and possibly try implementing some vehicle code, too )

Gah, don't tease me like that!
[...]
But if you were planning to add something in anyway...

Hehehe... I'll do my best, but please don't expect results too soon. I try to change the code in a manner that is generally useful, which unfortunately means that sometimes (like recently with the scripting) things can take a lot longer than planned.

But I am working on the game code again, and hope to make some progress soon both in its overall design and usability, as well as specifically in new features.

[Stoo]

Well, yes, that's true:
Before the player enters the vehicle, we have two distinct entities: the player and the vehicle.

When the player enters the vehicle, it must internally change its "state" as discussed earlier, which only means that it now has to do something else with the player input than before, namely process vehicle physics rather than walking physics.

It's difficult to say, and all very theoretically, without a concrete example, which of the two entities - if any - should be made "invisible" and how exactly the two entities should be kept in sync during the tour...

But I'm sure things will fall into place once they're implemented.

Probably; and of course we're also implementing very different playstyles. Part of the reason I'm interested in keeping the vehicle movement code seperate is because I *really* need the bots to be able to jump in and out as well; so it seems to make more sense to keep the movement code in one place and just worry about their different control schemes. Still need to consider whether it makes more sense to have the bots translate their intention into actions similar to the players', though... Like you said, need to get a little further into the implementation :p

Which still leaves one of the original questions - is there any way to attach the camera to something other than the HumanPlayer entity?

Btw., do you happen to have a car model that I could use for testing?

Actually, since I'm more mech-focused, I've been using the Sentinel model as a stand-in, and just doubled the dimensions of its bounding box...

Hehehe... I'll do my best, but please don't expect results too soon. I try to change the code in a manner that is generally useful, which unfortunately means that sometimes (like recently with the scripting) things can take a lot longer than planned.

Oh, no problem - I saw it was on your wishlist, but didn't figure you'd get to it too quickly; that's why I started trying for it in the first place Actually planned to post it, if I can get it to a useable point.

[Carsten]

Part of the reason I'm interested in keeping the vehicle movement code seperate is because I *really* need the bots to be able to jump in and out as well;

Ah, ok!

so it seems to make more sense to keep the movement code in one place and just worry about their different control schemes. Still need to consider whether it makes more sense to have the bots translate their intention into actions similar to the players', though...

Yes, that's another part that comes up when also bots should drive -- a subpart or kind of AI logic.

Which still leaves one of the original questions - is there any way to attach the camera to something other than the HumanPlayer entity?

Not really, the HumanPlayer "is" the camera.
Although it is clear that we eventually need a better separation of player input (PlayerCommands) and camera, e.g. for 3rd person view, vehicles, or chess-like games, the close connection of the camera to the human player is due to the prediction/reprediction that is going on behind the scene.

This is also why I suggested to consider the human player less as the bipedal walking human that it normally is, but rather than something more general - the camera - that (for the person watching the monitor) can be a walking or a driving (or flying, ...) entity.

Btw., do you happen to have a car model that I could use for testing?

Actually, since I'm more mech-focused, I've been using the Sentinel model as a stand-in, and just doubled the dimensions of its bounding box...

ok!

Oh, no problem - I saw it was on your wishlist, but didn't figure you'd get to it too quickly; that's why I started trying for it in the first place Actually planned to post it, if I can get it to a useable point.

Ok, thanks for the info!

[Stoo]

Not really, the HumanPlayer "is" the camera.
Although it is clear that we eventually need a better separation of player input (PlayerCommands) and camera, e.g. for 3rd person view, vehicles, or chess-like games, the close connection of the camera to the human player is due to the prediction/reprediction that is going on behind the scene.

This is also why I suggested to consider the human player less as the bipedal walking human that it normally is, but rather than something more general - the camera - that (for the person watching the monitor) can be a walking or a driving (or flying, ...) entity.

Another possible advantage if you can divorce the camera from the player - camera views in world guis! (I have *no* idea how hard that is to pull off, of course - but it'd be awesome! )

More topically, though - I could just pin the player to the vehicle for now, since they should be in a frozenspectator-equivalent state (aside from command issueing) when driving - no player rendering, no physics, just keyboard/mouse inputs. And joystick, whenever I get to that point

[Carsten]

Another possible advantage if you can divorce the camera from the player - camera views in world guis! (I have *no* idea how hard that is to pull off, of course - but it'd be awesome! )

(I assume you refer to something like "surveillance cameras" in "camera views in world guis!" ?)

Yes, this would be nice, but it requires rendering the (surveillance) camera frame to a texture buffer, then rendering this in turn as part of a GUI desktop from the player cameras perspective. The same technique (render-to-texture) also has many other uses, and thus the plan is to implement it universally.

More topically, though - I could just pin the player to the vehicle for now, since they should be in a frozenspectator-equivalent state (aside from command issueing) when driving - no player rendering, no physics, just keyboard/mouse inputs. And joystick, whenever I get to that point

Yes, that sounds like a good plan.

(Joystick input requires re-introducing DirectInput under Windows. I can't help you much with it, but it shouldn't be a big problem.)