As part of Hacktoberfest (https://hacktoberfest.digitalocean.com/) I want to add a feature to this game that is a big annoyance to myself and lots of others - mutli-vehicle connections. This would work like a trailer hitch, or a railway coupling, so that you can have your shopping cart hitched up to the back of your RV.
I would see it working something like this; have a new vehicle coupler part in the vehicle construction menu (requirements TBD). Mechanically, when it is within a tile of another vehicle’s coupler, it can be toggled on/off in the vehicle control menu. When toggled on, the two vehicles would become a single entity. Since all resource objects (fuel tanks, batteries, turret ammo) are local to their respective parts, when you connect or disconnect the vehicles they would keep whatever amount of their resources they have remaining at their locations.
I wanted to check in before I got too far along to see if this seems like a feasible approach to everyone else, or if there is a better idea out there for how it should work from a game mechanics perspective. Thanks for any feedback you can provide.
This would be moderately hard and not all that realistic, but the idea itself would work.
The biggest problem in the implementation is that we currently have no vehicle merging/splitting functions.
Notice that when bashing wrecks, you can only back those parts which aren’t necessary for the vehicle to stay connected - for example you can’t destroy the middle tile of a bicycle until you destroy one of the wheel tiles.
The problem with realism would be that combining vehicles into a single entity would mean only one direction/momentum/velocity for both vehicles. This would look very stiff, as both vehicles would turn at the same rate.
As for the implementation details:
First, you’d want to check if the vehicles are aligned - rotated in the same direction. If they aren’t, you could try correcting that or just fail - both are fine.
When combining vehicles, you’d have to add all the parts from one vehicle to the other one. This would require translating their mount points, as mount points are centered around their current vehicle’s point (0,0).
Then you’d combine their configuration. All the bools at the end of vehicle.h.
You’d have to make sure the old vehicle isn’t the same vehicle as g->remoteveh(), if it is you’d change remoteveh to the new vehicle.
Finally you’d remove the old vehicle.
Now, splitting:
First you’d need to find which parts belong to which vehicle. If the coupler was the ONLY part connecting those two vehicles, finding which vehicle ends where would be easy. Except for the coupler - this one would need to store that data somewhere.
If the vehicles could be adjacent to each other at the time of coupling, you’d need to store some sort of vehicle ID per part. And not just that - some parts could be added (or even worse - removed) after coupling. You’d need to somehow decide which vehicle gets which part in such a case, making sure that it splits into two vehicles and each of those is a single entity without disconnected “floaters”.
Then you’d remove some parts from the coupled vehicle and add it to a new vehicle, basically inverting the coupling.
Finally settings - just copying the settings of the old vehicle and then verifying they’re correct (vehicle with no reactor can’t have active reactor, for example) should be enough.
I think the biggest problem you are going to run into here isn’t going to be the coupling/decoupling aspect, it’s going to be the physics of moving round with a trailer. As Coolthulu has pointed out, any sort of “make them both into 1 vehicle” is going to look very stiff; you are essentially making your vehicle into just one super long semi truck at that point.
That said honestly you probably aren’t going to get a much better system than that without a bit of a rework/expansion of our car mechanics (for anyone interested check this out). Once we have a car system that actually works based on applied forces distributed around the car adding realistic trailer movement becomes an exercise in simplicity, all you need to do is add 1 more force point on both the car and the trailer (i.e. the tension in the hitch) and all the math handles it just fine.
That’s pretty much where the idea is, making the linkage rigid makes the entire exercise pointless, and making the linkage a pivot point makes it very difficult. I’d love to be proven wrong about the second though.
The simplest thing I can think of for a flexible linkage is for the towed vehicle to rotate to face the linkage point, then advance to make contact if needed. Unfortunately this doesn’t solve the problem of backing up. Also it requires overhauling the vehicle rotation code to allow a wider range of rotations, I don’t think the existing selection of rotations is going to work very well.
What I’d thought of for overhauling rotation is to replace the current functionality where the vehicle pivots on its center with one where some wheels are designated as “steering wheels”, and when turning, the vehicle rotates such that the steering wheels move one square to the left or right of straight ahead, little illustration of wheel movements when the vehicle is facing north or NW:
123 23
S 1S
S is where the wheel starts, if the player is steering right, the wheel moves to 1, if steering left, the wheel moves to 3, and if driving straight the wheel moves to 2. So for example if the plaer is driving due north at 5 squares per round, and steers left for one round, the progression of the vehicle’s (front, steering) wheels would look something like:
5
5 4
4 3
32 2
1 1
S S
Basically the steering wheels pull the vehicle laterally, which drives rotating the vehicle, instead of just rorating the vehicle in the first place. I think this would make for smoother steering, but we might want to add something to handle different degrees of steering.