Vehicles

[eightvirtues]

Without having a good understanding of the underlying engine/code that governs Nexuiz, as a programmer I'm a big advocate of creative kludges for limited purposes. It may be that the Quake engine would allow for vehicle "physics" using the underlying gameplay mechanisms. Limiting the scope of gameplay using vehicles should be faster (development/resource-wise) and easier than incorporating a dedicated physics library, and provide maybe a whole new level of gameplay at minimal cost.

I have a few questions though, hopefully helping to spawn some ideas about how this could be accomplished. If client/server checks were suspended for physics routines, could additional "hypothetical" next frame calculations be made per frame when in a vehicle (five samples @ 30 fps) to project the angle at which the model should be represented? If so, the average of the orientation vectors for the next five or so frames could provide a vector for the currently displayed orientation. That would take away the "binary" orientation and give some measure of smoothness to flying over hills.

That leads me to my next question: Is it possible, while only translating players' positions, to control the visual orientation of the player models? If so, then the previously-projected orientation vector could be applied to the visual representation of the player model to simulate smooth orientational changes due to terrain, etc. I recommend avoiding complex crash/damage calculations, even at first for landing up-side down.

Finally (as this is the heart of limited physics for vehicles) is it possible to give a greater preference to inertia in calculating the next position of a player than to left or right movement? When playing Nexuiz I know my model doesn't stop immediately, meaning there is code that controls inertia with respect to player position. The forward momentum would need to be made much stronger than left/right movements. There should be an inversely-proportional relationship between forward momentum/inertia and left/right movement strength. Pressing the down arrow would need to work against the player's inertia at a fixed rate, and left and right would need to be reversed when the player was moving backward (pressing down while the player's position is moving backward [has negative inertia/momentum]).

Of course, this is a creative kludge like I was saying, but if possible would be a hell of a mod were the proper vehicle models available. Guess my point is, if this is a Quake mod, it should really take its root code to its limits.

As an aside, does anyone know of any code like Mediawiki that allows easily posting and categorizing code, images, audio, and other binary data? I'm trying to build a wiki/database of FOSS game data.

[divVerent]

Sorry, but changing player movement in such a way is clearly out of the question, unless it is optional. Nexuiz is not meant to have realistic player physics.

For vehicles, the movement physics may be arbitrary of course.

[eightvirtues]

Sorry, but changing player movement in such a way is clearly out of the question, unless it is optional. Nexuiz is not meant to have realistic player physics.

For vehicles, the movement physics may be arbitrary of course.

Is the Nexuiz code bound to the original projects, or have they been made static with modifications added? Just wondering why some additional modifiers can't be made to the variables controlling player position and visual orientation. But really, can visual model orientation be controlled at all?

Also, what do you mean "unless it is optional"? I'm talking about poor excuses for physics, definitely not anything more robust like a physics library or major code change.

[MirceaKitsune]

I kept thinking more about this in the last days and this is what I came with; For vehicles to work there will indeed be a lot of things needed which are hard to implement but 99% necessary, mainly Physics and probably a lot of code as discussed. However, what I'm mainly seeing now is that if anyone wants us to have vehicles at all we need to start from somewhere and do what we can using what we currently have, otherwise we'll just be waiting for more and get nowhere or get where we want very slowly. We need to start doing something about this at all and from what I currently investigated, this in my opinion is the way to get started on the right foot using what Nexuiz -currently- supports:

First thing to start with is implementing an entity which can be placed on the map like a weapon that a player can approach, and when getting close enough to it and pressing the Action button (a keybind which would need to be implemented too) the player would then get stuck to that entity / model while playing a sit animation and be able to move around the map stuck to it like that. So the first thing that must be possible is for the player to go to an entity on the map, click a button near it to sit on it then move around the map while the player model and that entity's model (which in a more advanced phase will be a vehicle mesh) are stuck to one another in a certain position. Then when pressing the action button again, that entity and the player model would separate from one another in the location the button was pressed at and everything would get back to normal until the player would re-board that entity from where it left it. This would be the first alpha phase of any usable vehicle system and the first thing that would need implementation whatever physics engine or further code would be to come.

Once that is done and working, the second thing to do would be to change the handling, speed, acceleration and friction of the player while the entity is being sat on and the player walks 'stuck' to it, as well as make the player take less damage while in the vehicle (at least in an alpha phase until vehicles will have their own health). Also collisions should be different and make the player stop differently in walls... and let's not forget the different collision plane for the player which shall now be bigger (although that is set with the model when that will be done). A lot of this will indeed require a physics engine to be in, I'm only referring to what is possible with the current simulated physics that Nexuiz has or nothing more (at least the maximum speed and acceleration of the player can be set, as well as the gravity as proved by the Low Gravity mutator).

Third thing to accomplish once the first two are done (although this can be done before the second one above of course) is to make the player have different firing types while riding the entity. As it's the case in most sci-fi shooter games like ut2k4 or Halo, vehicles have their own primary fire and secondary fire while being sat in. So while the player is riding such a vehicle the firing types of his/her weapon must be changed to that vehicle type's and only return to normal once the player exits the vehicle.

The fourth thing then would be the eye-candy stuff... mainly making an ambient engine sound that would emanate from the player / entity while it's being used as well as the collision sounds and of course a vehicle model. Also don't forget that when riding a vehicle the player must be in 3rd person mode, not 1st person. This will further on be a preference of course but by default the user must have a 3rd person camera while riding vehicles so that's another thing quite high on the list.

So yeah, until physics engines and the heavier code can be implemented in the game this is something that can be worked on so far... at least part of it. If we get these things ready first, when a physics engine will come we will be ready with all other systems for vehicles and things will be linked together and implemented in no time. Until then of course they won't really work that well, mainly in the fact vehicles wouldn't orient correctly over hills and ramps and other things wouldn't be as realistic but still, -most- of what vehicles will need can be done currently. So I for one suggest we start working on implementing what I listed above at least the first point which is essential anytime someone is willing to try, so we can even have the smallest hope of implementing vehicles.

[MirceaKitsune]

Today I've given further thought to this and thought to continue the post above and what I have been thinking about and noticed. Note that I may be 'pointing the obvious' in some ways so if I'm mentioning something too easy to find or figure out please don't mind that... I'm just curious on how this can be done the best way over the current system really. So yeah, this is what I found;

Regarding the system of making an entity that sticks to the player and changes its speed / acceleration / health, etc; After looking a little through stuff I was surprised to see that such a system is already implemented and right under our nose. The entities in Nexuiz that stick to the players and change their characteristics are the runes in the Rune gametype. The player starts out normally then when finding a rune and walking into it, the rune sticks to that player and makes him/her slower but with a stronger attack, faster but more vulnerable, etc. So to make a vehicle, the code in one of these runes could be partially re-used. Technically, the vehicle would be a lot like a rune since it would stick to the player while changing handling and health in different ways. So yeah that's a code already in the game which can be taken and re-used for this.

Second thing, related to the problem of how the vehicle would handle over non-straight surfaces... I think this could be at least a temporary system though I believe it would be the best one to go with all the way; Each vehicle could have 4 sensors placed on it's bottom on all four corners of the vehicle model. Every time the vehicle would move / change its position then, these sensors would rotate and reposition the vehicle model so that each of them tries to be exactly at the level of the surface the vehicle is sitting on (in the case of a 4 wheel vehicle the best position for such sensors is right on the bottom-middle of each wheel). Only difficulty here is what would be done when the vehicle sits on 3 wheels and one is in the air, in which case it would normally try to lean towards the side it doesn't touch depending on its center of weight, and also what would be done when a ground vehicle is thrown above in the air (a temporary way would be to position it still over the ground... that wouldn't be pretty noticeable unless the vehicle jumps way too high up).

This is probably the way it's done for many vehicles so I hope me posting this wasn't stupid.. just wanted to bring up this idea if anyone is willing to try and play with the technology of a model that tries to always face the position of the ground based on 4 corner sensors. So yeah, if that gives any more inspiration in any way I hope that helps

[arew264]

I think the devs haven't made this clear enough, so let me echo it a bit.

Nexuiz does not in any way support any of the components of vehicular motion. Nexuiz supports collision detection of vertical boxes. The boxes do not pitch. The boxes do not affect the animation except by translating it. There is no concept of forces, and only a limited implementation of inertia.

Sure, you could put a bike in the current code, it wouldn't be that hard. The problem isn't adding the bike, allowing the player to mount the bike, or making the bike move, the problem is that the bike could only travel over flat surfaces while maintaining a barely plausible appearance, and the animation wouldn't sync to the speed of the bike.
The bike would be perfectly stiff, there would be no suspension action, there would be no movement at all, and it would be so unrealistic that it would look just as good as a player standing on a crate that's flying across the landscape.

If you added vertical rotation of the box, you would have to rework what little physics the entire game has, and while gameplay wouldn't be severely affected, it would be a pain to code... for what? It would still look like a player sitting on a box, but the box could tilt up and down unrealistically as well as moving unrealistically.

Adding full physics would change feel of the game entirely, so no one really wants to rework such a huge codebase for no assured reward. Time would be better spent writing an engine from scratch that had full physics than trying to rework Nexuiz to support the same thing. The whole structure of the code would have to change, and it's not going to happen any time soon.

To sum it up:
Nexuiz handles vertical boxes. There just happen to be animations in the boxes. Vehicles could be put into such boxes, but they would be so unrealistic that it would, in the view of many people, make the game worse rather than better. There would be no realism; there would be no action and reaction; there would just be a static model that moved back and forth, turned, and (with significant effort and a significant restructuring of the code) pitched. There would be no roll. There could be some sort of flight, I guess, but when the model hit the ground again, once again, there would be no action reaction, no realistic movement, nothing. Just a perfectly solid box hitting the ground. If pitch code was added, the box could roll over backwards, but it would look like a bike floating upside down, most likely not touching the ground.

I hate to shatter dreams like this, but you haven't been grasping the concept. Vehicle physics require a whole new level of physics that anything based on Quake 1 simply will not attain without becoming something entirely unlike Quake 1. It's a good thought, but not anywhere close to a realistic one.

[Alien]

All physics is inside qc code. Darkplaces allows you to have whatever physics you like. No need to rewrite the engine.

[arew264]

Be that as it may, the addition of any new physics techniques would require the old code to be restructured or things would break in strange ways. What I've said still applies. A major overhaul is just not feasible, or such is my view. I don't know the details of the Nexuiz though; this is my speculation based on my knowledge of Quake.

[[-z-]]

Pretty vague and optimistic of you Alien, considering Urre's struggle with physics in QuakeC.

[Alien]

Yeah, pretty optimistic considering this: http://box2d-js.sourceforge.net/index2.html